I looked into a non-conda solution when I tried to integrate a python setup into IJulia's setup (the effort was finally superseded by the Conda.jl package).
pip had come a long way and would have worked for the case. I also think that wheels pretty much solve the binary distribution problem for packages on windows that had probably prompted the creation of conda in the first place. The thing that never really worked was a private (portable) minimal python installation that didn't register itself into the system. I discussed that with the python devs on their mailing list and the general response was "that is just not something that is supported, it might work, or not". There are two issues around this: 1) you need to get the binaries into a directory on the users machine and 2) you need to be sure that when you start python.exe from that private directory, it ONLY loads things from this private python installation, and doesn't go out to load/modify stuff from/in any system installed python. For 1), I ended up installing the windows binaries, then zipping up the python directory, hosting that on sourceforge, and then downloading and extracting that in the builds.jl script. Everything worked, but obviously this is not a solid way to handle this, i.e. to host my own binaries of python. I asked on the python-dev list whether there was any chance that python.org might just host a zip file like this, and they said no (at least for the time being). For 2), I think the python devs think that this is not guaranteed at all by the current python.exe. In my own testing, everything worked, but I certainly didn't test all corner cases. I doubt that conda does any better, my guess is that they also are just lucky that everything works (but I might be wrong, maybe their fork is more extensive than I know). So, I think the main blocking thing right now is that there doesn't exist a "minimal portable python" distribution, that just is a zip that has python and pip in it. Cheers, David > -----Original Message----- > From: [email protected] [mailto:julia- > [email protected]] On Behalf Of Tony Kelman > Sent: Monday, November 2, 2015 1:23 PM > To: julia-users <[email protected]> > Subject: [julia-users] Anaconda Python > > Forks are good. The pure Python ecosystem and core language developers > have left package management and distribution in a very broken state for > the scientific stack for way too long, and Continuum had to come in and fix > the situation themselves. They did so, users followed, and they even > released the result as open source under a compatible license. The rest of > the python ecosystem has demonstrated unmitigated tone deafness to the > requirements of the scientific ecosystem by not learning from and adopting > more of the way conda does things. > > Does winpython have a minimal core and a binary-only package management > system on top of it? Do they have binaries for the likes of scipy, matplotlib, > jupyter etc that work with pycall and ijulia? We can consider supporting it > if it > works, but if it doesn't work as well as Conda we shouldn't endorse it. > Working software is what matters to users, more than ideology. > > If someone wants to fork Julia or its package management, we would > welcome the brainstorming of ideas and as long as the license of any new > additions remains MIT, we can incorporate the improvements. Most forkers > would rather fold their improvements back upstream, eventually, especially > with large fast-moving projects. Look at what happened with io.js and > node.js over the last year. Python-dev should have done the same, but they > didn't.
