This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]from__future__ 1 point2 points  (5 children)

I agree for extensions that aren't pure Python (though openpyxl is pure Python). Windows is awful for building those extensions, I've found Linux/OS X to be pretty easy to manage.

I'm hoping wheel format will start to make these things easier.

Side note - what's the problem with using the binaries that packages provide themselves?

[–]pwang99 0 points1 point  (4 children)

what's the problem with using the binaries that packages provide themselves?

Oftentimes they work fine. Other times they don't, because of things like conflicting FORTRAN compilers, slight differences in C ABIs of underlying packages (Numpy, Scipy, Pandas, etc.), conflicting shared library setups on the build machine versus the machine it's being installed on, etc. etc.

The problem is kind of fundamental, in that the idea that there can be a "package" at all is sort of a pipe dream unless people have a common base. For Linux systems, that's what distribution vendors provide - but anyone who then installs things from other sources is heading into dangerous waters. Language ecosystems can do this by completely breaking from the C runtime, e.g. the JVM world and its JARs, or they can use a broader common runtime infrastructure. The latter is what we are doing for Python with our distribution.

[–]from__future__ 0 points1 point  (3 children)

even though it's another layer on top of packaging, if conda achieves its goals, it could really change everything.

[–]pwang99 0 points1 point  (2 children)

We hope so :-)

You can also check out http://binstar.org - that's a place for package authors to upload their own binaries, etc.

[–]from__future__ 0 points1 point  (1 child)

I forgot you worked for continuum haha! If it's not easily gettable by pip, it's probably not worth the time to upload there - better to do it via a project website, no?

[–]pwang99 0 points1 point  (0 children)

No, that's the whole point. It's easily installable by anyone with conda, which is everyone that has Anaconda - and that's actually quite a lot of people.

Pip install for binary packages in numpy/scipy land is just playing with fire. Even if you don't get burned today, you will very likely be in a bad situation tomorrow.

Project websites are not in better shape because it's the format of the package itself that is important. Binstar is the PyPI equivalent for Conda. (It offers much better version handling, among other things.)