Blogged : Delphi Package Manager RFC

[dummzeuch 1505]

6 hours ago, Vincent Parrett said:

@Remy Lebeau That does still work, however it still doesn't allow you to install multiple versions of the same package, which makes life difficult. 

 

For example, on v7 I might use packageA.1.0.0 and on v8 I might use packageA2.2.0 - I don't want to update v7 to use the newer packageA, for a bunch of possible reasons.

I never tried it but it should be possible to have multiple registry branches for each of the package versions and then start the IDE with the appropriate -R switch.

 

Has anybody ever used this (for longer than 10 minutes 😉 ) ?

[Uwe Raabe 2057]

1 hour ago, dummzeuch said:

Has anybody ever used this (for longer than 10 minutes 😉 ) ?

I do most of my development like that (my Desktop and Taskbar are plastered with Delphi icons). Some IDEs have their libraries set to English language while others are set to German. If you work for different customers you don't want to end up installing a plethora of components into your IDE to cover all those different projects. Often I have to stick with a specific version of components due to customer demand. Have two customers with disjunct demands and you know what @Vincent Parrett is talking about. That said, I guess I belong to the dedicated target audience for such a tool!

[timfrost 78]

I regret to say that as a library consumer I agree with Stephan Glienke on this. Instead of a package manager I already have an excellent tool to control all the third-party Delphi libraries we use. It's called FinalBuilder(!), and it does everything I need to build these libraries (and a few of our own) from source, and install all the design packages. This ensures that the source/DCU/BPL/DCP files are all where I expect them to be, not scattered around my drives at the whim of a third-party developer.

 

There is a set procedure I follow for new Delphi versions, and a simple set of changes to make to a cloned copy of the Finalbuilder target for a new compiler and a new main folder of our Delphi source and library folders. For library upgrades, I never install a new library automatically into a production environment (so I will never use a "package manager"). Instead I install the source elsewhere, and first review all the changes with Beyond Compare (and apply our few source changes and fixes if still needed), before allowing them near the production development environment. I find from long experience that this the best way to eliminate surprises on upgrades.  Separate targets in Finalbuilder can be conditioned to continue building with the old version, with perhaps older library versions also, while testing the new one.

 

There are a couple of annoying third-party library installers we use, where it is impossible to turn off the 'build' process after install. For these I keep an old VM where I can run the installer, then move the source so that I can control the installation with our FinalBuilder project.

 

For a few .Net applications we have needed, I have used Nuget for third-party libraries. Yes, the source and solution files get installed, and it is possible to modify source if needed (for each upgrade). But that is only possible, I believe, because the development environment has been designed, and Nuget integrated, to make this simple. Nobody could make that claim for Delphi, and that is why having a Finalbuilder project to do all this makes it so simple.

 

I congratulate Vincent for having the vision to try to solve the packages issue for Delphi, but sadly I have to hope that it takes a long time before third-party vendors take it up and try to force me to use it!  I do concede, however, that a feature like this would certainly help and encourage new users, and perhaps large teams, to make use of third-party libraries; but for sites with mature applications with a good number of libraries, and who need to manage changes carefully, I can only see new problems.
 

[Vincent Parrett 750]

@timfrost Thanks for your feedback. Funnily enough, I do exactly what you do with my array of third party packages right now, but it's not really optimal (even with a great tool like FinalBuilder 😉 ). Taking updates to packages is still problematic/manual and error prone, and this is really still a global thing rather than per project. I want to open a project in the IDE, and know that all my dependencies are present and correct, just we do now with nuget. 

 

As you would expect from a company that sells a CI Server, we do lots of CI builds, and building all the third party code from source with every build is painful to say the least, it almost doubles our build times. Building them once on install would speed up the build process dramatically. Of course there will still be the option to just use the source, and an option to turn off compilation on install. Authors/Vendors will have the option to choose what they distribute, source code, pre-compiled binaries or both, the option to compile on install (which users can override).  

 

This project is going to take some time, there are so many variables, every author/vendor does things differently, so we'll need to consider all the variables and come up with something that hopefully works for the majority.  

I don't have the power to force this on anyone, nor would I want to. I'm just trying to create some order out of the current random chaos that exists now.  

[Uwe Raabe 2057]

Perhaps I am a bit too optimistic, but I do have hope that some library providers will adhere to a reasonable standard whenever it will be established. If this Package Manager forces some requirements on any package/library to be supported, that might help to canalize the chaos diversity currently out there.

[Georgge Bakh 29]

On 2/26/2019 at 1:41 AM, Uwe Raabe said:

Perhaps I am a bit too optimistic, but I do have hope that some library providers will adhere to a reasonable standard whenever it will be established. If this Package Manager forces some requirements on any package/library to be supported, that might help to canalize the chaos diversity currently out there.

With dependency management done right libraries will become simpler, easier to maintain and of course more uniform.

Edited February 28, 2019 by Georgge Bakh