More on the necessity and difficulty of a package management system

[Bruno Medeiros]

On 26/01/2011 22:45, Andrei Alexandrescu wrote:
> Seems to be unduly difficult in Python:
>
> http://www.google.com/buzz/michael.bruntonspall/AcMtiMEUgZ2/Packaging-and-deploying-python-web-apps
>
>
> We need to have a good solution for D.
>
>
> Andrei


I'm not really familiar with Python so I didn't understand all the 
implications with the issues he encountered on that article. From what I 
understand, Python on its own (the Python installation) does not allow 
multiple versions of the same library to be installed on it, thus the 
necessity of virtualenv. If that is the case, that seems a pretty bad 
design to me, for the reasons he mentioned. virtualenv should be the 
default way to do things. I mean, it's DLL Hell all over again, only in 
a different platform (Python runtime instead of Windows). People keep 
making the same mistakes...


As for the rest of the article, well, it's mostly about web application 
deployment, which is a different concern (although related) to a package 
and version management system. We don't even have anything to deploy to 
in D, AFAIK.


In my view, these are the features/concerns that should be considered 
for a package management system:

1: "package" version and dependency management (ie, verifying the 
correct dependencies are present)
2: A well defined, structured, and hopefully platform independent, way 
to compile source "packages", transforming them into binary "packages".
3: Adding, removing, or updating "packages" from some shared repository 
online (either a central repository or not).
4: A way to publish new "packages" into shared repositories (either a 
central repository or not).

5: Additional I would also like the possibility to add another layer of 
visibility/encapsulation to "packages", that is, to specify which 
modules/types/packages/etc should be visible to external "packages". 
This idea is taken from OSGi, and it would subsume the need for this:
http://d.puremagic.com/issues/show_bug.cgi?id=2529
  , and is generally a very nice mechanism to expose a clean API, that 
may not be possible with D's protection modifiers (public, private, 
etc.) alone, for large projects at least.


I think concerns 1, 2, 5 are the most important ones (4 not so much). 
Concern 2 however, is likely also the hardest one to implement, by far. 
(note the "structured" and "platform-independent" qualifiers... we 
should strive to stay clear from make/automake crap and the likes as far 
away as possible)

1 and 5 are particularly of interest to me, because it is the way I 
would like to implement project dependencies in DDT, from the start, 
instead of having something which is just IDE specific. Much better to 
have a toolchain standard.

-- 
Bruno Medeiros - Software Engineer