> On Tue, Dec 29, 2009 at 3:49 AM, Dag Sverre Seljebotn > <da...@student.matnat.uio.no> wrote: > >> >> Do you here mean automatic generation of Ubuntu debs, Debian debs, >> Windows >> MSI installer, Windows EXE installer, and so on? (If so then great!) > > Yes (although this is not yet implemented). In particular on windows, > I want to implement a scheme so that you can convert from eggs to .exe > and vice et versa, so people can still install as exe (or msi), even > though the method would default to eggs. > >> If this is the goal, I wonder if one looks outside of Python-land one >> might find something that already does this -- there's a lot of >> different >> package format, "Linux meta-distributions", "install everywhere >> packages" >> and so on. > > Yes, there are things like 0install or autopackage. I think those are > deemed to fail, as long as it is not supported thoroughly by the > distribution. Instead, my goal here is much simpler: producing > rpm/deb. It does not solve every issue (install by non root, multiple > // versions), but one has to be realistic :) > > I think automatically built rpm/deb, easy integration with native > method can solve a lot of issues already. > >> >> - Currently I'm making a Sage SPKG for CHOLMOD. This essentially gets >> the >> job done by not bothering about the problem, not even using the >> OS-installed Python. >> >> Something that would spit out both Sage SPKGs, Ubuntu debs, Windows >> installers, both with Python code and C/Fortran code or a mix (and put >> both in the place preferred by the system in question), seems ideal. Of >> course one would still need to make sure that the code builds properly >> everywhere, but just solving the distribution part of this would be a >> huge >> step ahead. > > On windows, this issue may be solved using eggs: enstaller has a > feature where dll put in a special location of an egg are installed in > python such as they are found by the OS loader. One could have > mechanisms based on $ORIGIN + rpath on linux to solve this issue for > local installs on Linux, etc... > > But again, one has to be realistic on the goals. With toydist, I want > to remove all the pile of magic, hacks built on top of distutils so > that people can again hack their own solutions, as it should have been > from the start (that's a big plus of python in general). It won't > magically solve every issue out there, but it would hopefully help > people to make their own. > > Bundling solutions like SAGE, EPD, etc... are still the most robust > ways to deal with those issues in general, and I do not intended to > replace those. > >> What I'm saying is that this is a software distribution problem in >> general, and I'm afraid that Python-specific solutions are too narrow. > > Distribution is a hard problem. Instead of pushing a very narrow (and > mostly ill-funded) view of how people should do things like > distutils/setuptools/pip/buildout do, I want people to be able to be > able to build their own solutions. No more "use this magic stick v > 4.0.3.3.14svn1234, trust me it work you don't have to understand" > which is too prevalant with those tools, which has always felt deeply > unpythonic to me.
Thanks, this cleared things up, and I like the direction this is heading. Thanks a lot for doing this! Dag Sverre ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel