Package Magician and Search Paths

Some people using Package Magician or evaluating it asked me to add some sort of search path handling. The usual scenario is that a library installed into the IDE via its setup also adjusts the global library path pointing to the necessary DCU files. Some libraries consist of quite a bunch of packages to be installed into the IDE and thus are not easy to be installed manually, so using the setup is a reasonable option.

Now assume f.i. you have access to the beta version of that library and want to test it with some of your projects, but you still need the release version for your production environment. Let’s further assume you have set up Package Magician to handle the loading and unloading of the respective packages depending on the current project. The problem now lies in the global library path still pointing to either the release DCUs of this library or the beta ones.

Let’s take one step back: Package Magician was built in the first place to handle different design time packages on a per project basis because the IDE is not capable to do this in a usable way. The settings are stored in a separate project specific file that should be under version control. I could as well have opted for storing the settings inside the DPROJ file, but that one is already cluttered with things not to be under version control and I didn’t want to complicate things further.

So while the IDE lacks proper handling of design packages on a per project basis, it already supports search paths on a per project basis, rendering a similar feature inside Package Magician rather obsolete. All you have to do is to put the correct search paths into the project options and these will take precedence over those in the global library paths. As the DPROJ is usually also under version control, its content should always match the Package Manager settings.

Let me close with a personal opinion: It might be convenient for the lazy ones of us to have all library paths set as global – I have to plead guilty for that myself in the past. New projects will compile immediately no matter which component you drop on a form or which library unit you use. On the other hand you are likely to loose oversight of which libraries your project depends on. In the last years I have formed the habit of removing all third-party entries from the global library path and add only those directly to the project that are actually needed. This will not hinder me to drop any component on a form or use any unit I want. Latest when the compiler complains when it cannot find one of those units I am reminded to think about whether it is worth to add this dependency or better use an intrinsic routine or something already used by the project. Ever so often I am able to find a built in solution in Delphi that lets me abandon some code I used in the past – often complete libraries are not required anymore at all.

Remark: It might be worth reading this of my answers at StackOverflow regarding the order of search paths, the problems with localized versions of Delphi and a way to workaround those.