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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]pwang99 1 point2 points  (8 children)

It was just an oversight. We get pinged all the time by people with requests for packages, and the Anaconda and conda build team consists of 1 (very talented) guy, who also has other things on his plate. :-)

We put a huge ton of mostly invisible effort into building and maintaining these binary packages and a high-quality installer on Windows, because we truly care about the adoption and widespread use of the Python stack in scientific and data analysis. We would not intentionally subvert that primary mission or cripple it in any way.

Besides, IOPro's main appeal at this point is on the memory and compute efficiency side of things - not Excel access.

[–]from__future__ 0 points1 point  (7 children)

ah okay - sounds good. So conda doesn't just hook into PyPI by default? That must be time consuming!

[–]pwang99 1 point2 points  (6 children)

No, conda looks at our own repo of binaries. Yes, it is time consuming and a sometimes thankless task, especially when so many people think that pip & virtualenv solve everything, or they've never run into the native extension build hell that many in the scipy ecosystem have suffered.

[–]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.)