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
