Great and very necessary!

[jcangas]

Helo Vincent!. This is a great initiative!!!. Several years ago I create a package manager for Delphi. It has no sever side, so it is no "complete" and sure it can be better, but it is working in a few customers. Is here http://jcangas.github.io/DelphiVM/. Package format are simple zip files and package repos are simple folders. DelphiVM can resolve dependencies, compile sources and install the required IDE packages.

It was developed in Ruby language at sparse times, under pressure and with a lot of "ambition" (multi-IDE support, multi-platform support, can distribute complied, sources, docs, support for user tasks, can show and resolve your dependency tree, etc), so it don't have a good design, but I think we can learn some lessons from this experiment. Some points I found critical:

• FIRST at all: Define a standard folder structure for develop and deploy your packages. This way the package manager can know what need be packaged and what can be ignored, where found sources, dcus, etc. Also, after install, your IDE can know where found dcus, bpls or debug sources in an easy way. Other way, you need a very sophisticated package format file.

• Good package versioning and descriptive names. Something like mypackage-2.1.3+D250-Debug-Win32.zip, i.e, pack vs +IDE vs-Config-Platform will be necessary.

• Use https://semver.org helps a lot.

• Good package file specification format. Mine was inspired by ruby gem files, but other options can be good choices.

• IDE "per-project" isolation. I always start IDE with a -r parameter: is the only way you can ensure the packages dependencies don't conflict with other versions already installed.

Sure I forget something at this moment, but these points will be critical from my experience.

[vincentparrett]

Interesting that you chose to write it in Ruby rather than Delphi?

As for folder structure, there will be a package spec file, which will define the inputs and outputs to the packing process, and this process will produce a metadata file that is included with the package(zip) file.

Semver will be used, I already created a Semver library for delphi

[jcangas]

I selected Ruby in order to meet 2 goals:

• The user can extend/adapt it without recompile. He can add some scripts in dvm folder into their project folder. DelphiVM will search for extensions when it is invoked.
• Fast development reusing some existing work: rake gem. Rake gem is a sort of "make" in ruby capable of define aciclic graph of depending tasks and execute each task only one time.

About folder structure: yes, DelphiVM spec file already has some logic for maping project folders, but at the end it is a nightmare. Building the package is the easy part, but when you deploy you need adjust projects paths, and if you want allow compile from sources you need a lot of extra work. Moreover: I don't see the gain. I see a standard package structure as a great value favoring collaboration and reuse of work for Delphi community. Ruby gem and npm can create a folder estructure and basic spec file for your package. I think a Delphi package manager needs do it also. So, at least to reduce work for first version, I think is a good idea to have a standard folder estructure.