Any idea?
I was thinking just to hardcode the changes on the setup.py
and add the dependencies as usual
Hi @loumalouomega . Setuptools (and much of the Python Packaging infrastructure) doesn’t do much for managing dependencies outside of the Python ecosystem. Tools like pip and setuptools rely on system package managers (and developers) to have satisfied external dependencies (compilers, Python versions, other libraries) before running the tool. In this section of the Python Packaging User’s Guide, there’s some guidance about how a user might rely on something like Conda or Spack or other tools to manage and install some of the more complicated dependencies. Other packages like lxml and Pillow mainly rely on custom build-time routines (or sometimes just instructions) to ensure that build dependencies are present before statically linking libraries.
Some work has been drafted/discussed on declaring “external dependencies”, but to my knowledge none has matured to a useable state.
For now, I would suggest avoiding using setuptools and setup.py to manage these dependencies and would instead build a custom workflow to orchestrate first the preparation of the external dependencies and second the building of the Python package (setup.py or pyproject.toml) that assumes the presence of the external dependencies.
Some work has been drafted/discussed on declaring “external dependencies”, but to my knowledge none has matured to a useable state.
For now, I would suggest avoiding using setuptools and setup.py to manage these dependencies and would instead build a custom workflow to orchestrate first the preparation of the external dependencies and second the building of the Python package (setup.py or pyproject.toml) that assumes the presence of the external dependencies.
I was thinking in use poetry to deal with the dependencies
And adapt it to our case
But maybe I would do as youy suggest
Thank you very much
Hi! I am generating in a CMake workflow some libraries via pybind11 and install them already successfully. Now I am also generating a binary executable that I want to distribute with my wheel into a PATH location. Just adding the generated binary to
setup(..., scripts=['mytool']) does not work (not found) and just generating it in extdir installs it alongside the python prefix ('-DCMAKE_RUNTIME_OUTPUT_DIRECTORY=' + extdir), but does not add it to the PATH. What do you recommend to specify in setuptools:setup to install an executable that is generated from an external build?
This is what I am doing so far for libraries: https://github.com/openPMD/openPMD-api/blob/dev/setup.py
And a new executable named "openpmd-ls" comes in here: openPMD/openPMD-api#574
It's one of the higher-priority open questions to solve for the Python packaging ecosystem.
@pganssle do i recall it correctly that you are trying to solve editable installs for the peps - i was wondering, what if the solution was to generate a special wheel, tagged with
+for_editable_install that would contain metadata, a record and the files that the build backend would need to make things work
afterwards that wheel would be installed just like any other wheel, just that instead of shipping the package content, it ships a shim belonging to the controll of the backend
you mentioned its one of the higher-priority ones
Hi, we are currently encountering an installation problem with
easy_install.py ignoring a user-provided --prefix and trying to install in a system-location instead. Any ideas if that is a setuptools installation bug and how to work around it? pypa/setuptools#1930
@ax3l I wish I had a better answer for you, but the short answer is that the Python Packaging ecosystem has always been focused primarily on (sourcing python modules and packages) and (installing those modules and packages for use).
ERROR: Package 'setuptools' requires a different Python: 2.7.10 not in '>=3.5'
If you mean
pip install . for building setuptools.
If you mean
pip install . for building other stuff, then no.
setuptools-scm newcomer question: When I tag a release with tag
0.0.1 infers the version as 0.0.2.dev0+gf47c788.d20200221. Doesn't dev0 indicate that it's a clean tree (no changes between workspace and tag)? I'd prefer to use version 0.0.1 in cases where there aren't any changes from the tag. How would I achieve that?
As seen on Azure CI for Ubuntu 18.04
I have a python package I'm trying to create a new setup.py for. The package source lives under src/engine/MyPackage I'd like sdist and all the packages to omit the src/engine. The docs indicate that using
packages = find_packages("src/engine"),
package_dir={"":"src/engine"}, should do that, but I'm still seeing src/engine in the paths when I tar tvfz my sdist package. What am I doing wrong?
Hmm. looks like it's doing what I want when I build a wheel though..
@bdbaddog Regarding removing
src/engine from the sdist doesn’t really make sense. An sdist is essentially a copy of the source, prepared for distribution. It’s still expected that the setup.py will be run against the expanded source distribution, meaning that if your sdist were to remove the src/engine, the setup.py that uses package_dir={“”: “src/engine”} would no longer be valid. Why not remove src/engine, find_packages, and package_dir and just have ./MyPackage in your source?