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_INSTALL_PREFIX=PREFIX` and `make install` - or installed the zeromq from the conda package. Similarly, for a system-wide install on linux distribution, the same would hold with PREFIX=/usr On Mon, May 15, 2017 at 9:47 PM, Nathaniel Smith wrote:

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 distributions, conda) is to place binaries, headers, configuration and other artefacts for these components in their respective natural locations under the installation prefix (e.g. PREFIX/bin/, PREFIX/include/, PREFIX/etc/, PREFIX/share/).

Now, if I have a python package that depends on such a thing (e.g. pyzmq vs zmq), the pypi wheel for pyzmq will vendor a binary for libzmq as package data.

For the case of the header files, there is the distutils `install_headers` directive, but the target directory is (typically) under PREFIX/include/PythonX.Y, which is probably only a good choices for headers of a C extension linked with this specific python installation.

Would it make sense, when vendoring packages packages that don't depend on the python version in a wheel to use `data_files` instead, and target respectively the `bin`, `include`, `etc` and `share` subdirectories of the prefix?

Specifically, for the headers, one could do

data_files = [ ('include/foobar', [list of the foobar header files])), ],

Note: I was just using zmq as an example.

Thanks,

Sylvain

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

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 puts things under `CONDA_PREFIX/include/xtensor[-python]` and the Debian package `/usr/include/xtensor[-python]`. It seems that wheel's data_files can achieve that very simply, and was wondering if there was any drawback in this approach. Sylvain On Mon, May 15, 2017 at 11:45 PM, Nathaniel Smith wrote:

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 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_INSTALL_PREFIX=PREFIX` and `make install` - or installed the zeromq from the conda package.

Similarly, for a system-wide install on linux distribution, the same would hold with PREFIX=/usr

On Mon, May 15, 2017 at 9:47 PM, Nathaniel Smith wrote:

...

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 distributions, conda) is to place binaries, headers, configuration and other artefacts for these components in their respective natural locations under the installation prefix (e.g. PREFIX/bin/, PREFIX/include/, PREFIX/etc/, PREFIX/share/).

Now, if I have a python package that depends on such a thing (e.g. pyzmq vs zmq), the pypi wheel for pyzmq will vendor a binary for libzmq as package data.

For the case of the header files, there is the distutils `install_headers` directive, but the target directory is (typically) under PREFIX/include/PythonX.Y, which is probably only a good choices for headers of a C extension linked with this specific python installation.

Would it make sense, when vendoring packages packages that don't depend on the python version in a wheel to use `data_files` instead, and target respectively the `bin`, `include`, `etc` and `share` subdirectories of the prefix?

Specifically, for the headers, one could do

data_files = [ ('include/foobar', [list of the foobar header files])), ],

Note: I was just using zmq as an example.

Thanks,

Sylvain

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

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.