I started a proposal to add additional install paths to wheel. Maybe
something like this would be useful for your application, would you be
interested in finishing the proposal? If I was still working on it then I
would decouple it from wheel, come up with a good API for finding the
installed files
So I actually do use conda (and also maintain dozens of conda-forge
recipes). but I also need to package things on pypi and would like it to be
as consistent as possible with what general purpose package managers do.
___
Distutils-SIG maillist - Distuti
On 15 May 2017 at 22:42, Sylvain Corlay wrote:
> Let's say that you have an anaconda installation, and you install the latest
> pyzmq from pypi instead of from the conda recipe.
One of the key features of conda over pip is that it manages not just
Python packages, but also non-Python dependencies
OK thanks!
I want to create a pypi package for xtensor and xtensor-python, and would
like it to place the headers in the same location as with the conda package
or Debian packages.
(Which are essentially built with a regular
`cmake -D CMAKE_INSTALL_PREFIX=PREFIX; make install`)
The conda package
No, I'm trying to ask, like, why you want that. Presumably you have some
end goal in mind that you think this will help accomplish, and I think it
would be helpful to know what that is :-).
On May 15, 2017 2:42 PM, "Sylvain Corlay" wrote:
> Let's say that you have an anaconda installation, and y
Let's say that you have an anaconda installation, and you install the
latest pyzmq from pypi instead of from the conda recipe.
I would like the vendored libzmq to be placed under `PREFIX/bin` and the
headers under `PREFIX/include`, just as if I had either
- installed zmq with `cmake -D CMAKE_INS
What are you trying to accomplish by putting include files into virtualenvs?
On May 15, 2017 10:29 AM, "Sylvain Corlay" wrote:
> Hi,
>
> When distributing python packages that depend on non-python components,
> the typical way of doing this with general-purpose package managers (linux
> distribu
The goal in this approach would be to place headers, and binaries in the
same location as if they were installed with a separate package.
On Mon, May 15, 2017 at 7:29 PM, Sylvain Corlay
wrote:
> Hi,
>
> When distributing python packages that depend on non-python components,
> the typical way of
Hi,
When distributing python packages that depend on non-python components, the
typical way of doing this with general-purpose package managers (linux
distributions, conda) is to place binaries, headers, configuration and
other artefacts for these components in their respective natural locations
u
