> conda-build doesn't produce or consume wheels. It works by creating a
> > conda environment and running a shell script to install the python
> > into that environment
To be really clear -- conda build doesn't directly use ANY build/install
All files produced by the install
> > script are then put into a tar file, which is conda's version of a wheel.
right -- conda-build simply runs the script it is told to run (by the
recipe), and then looks and sees what files were installed.
In theory, one could build a conda package directly out of a binary wheel
-- after all, as mentioned, they are actually pretty similar, but most
folks would probably just use pip inside their conda-build recipe.
In fact, that is already being done -- most python packages are built with
"setup.py install", but some are built by using pip to install a wheel.
But I didn't think that the goal of PEP 517 was to ensconce pip as the only
way to install a package in Python.
So if a build system can install (like setuptools currently does), then
conda recipes may well call it directly.
I don't think this really has any bearing on the the PEP, though -- As I
understand it, the goal of the PEP is to formalize the interface between
build systems and package managers -- and that can only be a good thing for
other package managers.
NOTE: For the most part, folks want to use a pip-compatible install in
conda-build, because users tend to also directly use pip to install stuff
in conda environments e.g. if there is not a conda package available. If a
conda package were built with, say, plain distutils, then pip won't find
the meta data it's looking for, and might falsely see an unresolved
Personally, I've always avoided pip installing packages in conda --
preferring to make conda packages for all the deps I need, but conda-pip
compatibility has come a long way, so it does work fine for many users.
But it would be nice if packages didn't NEED to be pip installed -- but I
think that's an issue with the wheel spec (that may well be solved).
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
a while now i have wondered - why put version numbers into the dist info
not only makes it lookup more expensive (need to search for a
its also not serving a purpose, as the rest of the package is
unversioned at the root of site-packages.
in addition all those versions in folder names, that serve no purpose,
and create duplication/conflicts now creep into other peps as well,
please lets take a note at setuptools - for editable installs it wont
put a version in to the egg info folder
and imho thats the correct way to deal with data thats not actually
versioned at that level where its being stored.