On Sun, Aug 1, 2010 at 1:34 AM, Chris Withers <[email protected]> wrote: > David Cournapeau wrote: >> >> On Tue, Jul 27, 2010 at 5:36 PM, Chris Withers <[email protected]> >> wrote: >> >>> Indeed, but the other option requires a more complicated service to >>> query. >>> Being able to "serve" packages from a simple folder or from simple folder >>> served via svn or Apache is a huge win. >> >> I don't see how one preclude the other. > > How would you serve your proposed "rich" environment from Apache?
Debian repositories are mostly purely file-based + a few metadata for example. I mean, it is not like this issue have not been tackled for *decades*.... > >>>> The combination alone makes it complicated very fast. Trying >>>> to come up with such a scheme in python is foolish IMHO: the problem >>>> is complicated, and nobody has been able to solve it in a general >>>> manner anyway. >>> >>> I think that's overly pessemistic. What problems do you see with the >>> multiple-find-links suggestion I made above? >> >> It quickly becomes intractable once you have complex requirements. > > Again, I think you're being overly pessimistic. Please can you give an > actual example? Well, you do what you want from my suggestion, but I happen to know extremely well the packages and the issues you are tackling :) The issue is painstakingly obvious: you have to deal with N1 python version, N2 C++ ABIs, N3 Fortran ABIs, so you end up having an exponential explosion of situations. > >> I don't see how egg changes anything there compared to rpm/deb to that >> issue. At least, rpm/deb and the infrastructure around have been >> designed to somewhat deal with those issues, whereas egg clearly was >> not. > > rpm/deb focus only on their own operating system. They don't help with > Windows or MacOS. Eggs work the same on all platforms, from the clients > perspective, it's just a case of making the right eggs available that > appears to be problematic. But egg or rpm/deb is the least of your issue here... The problem is to make a set of binaries which work everywhere. And that's what is intractable on Linux in general. The advantage of rpm/deb is that it gives you a way to correctly manage the thing. > >> EPD can use eggs because they pretty much control the whole stack from >> python, hence significantly reducing the issues of dependencies >> issues. > > I don't follow. EPD uses a whole host of dependencies that are non-python... yes, but most of them are included in EPD. EPD installs its own python, its own swig, its own blas/lapack libraries, etc... which means the exponential explosion of situations mentioned before do not happen. > > Indeed, but as I said before, this is a constrained environment. > Ubuntu 8.04 or 10.04, each with a controllable list of installed packages. Then use .deb if you can, it will work so much better. You will somewhat have a guarantee that everything is built correctly and as expected. > With Windows and MacOSX, python packagers seem to go the route of statically > linking anyway... The mac situation is pretty awful. There are countless different python interpreters, each incompatible with each other. For Numpy/Scipy, we only target the official python.org binary, but even though, we still have tons of issues. The static linking is almost always a bad idea, and mostly because of distutils warts. Certainly, we want to go away from it as soon as possible (one of the goal of the packaging solution I am working on is to enable proper linking, but that requires a decent build tool instead of distutils) David _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
