[BUG] Deprecation warning when building wheels #2847
Comments
domdfcoding
added
bug
Needs Triage
|
Agreed this should be suppressed when building wheels. |
|
I am still experiencing this warning with setuptools 60.8.2 when using |
|
@mara004, this seems to be related to the way I recon the project needs to adhere to PEP 517 and PEP 518, i.e. a # pyproject.toml
[build-system]
requires = ["setuptools>=46.1.0", "wheel"]
build-backend = "setuptools.build_meta:__legacy__"
(I also recommend updating |
|
@abravalheri First of all, thanks for the response.
I am already running the latest pip version 22.0.3
Sorry, adding the above
What would I have to change so that the project does not rely on legacy behaviour? |
|
Hi @mara004,
The thing Recently,
The main difference between the legacy and the standard backend is that |
|
Thanks for the help, this is really appreciated. |
|
@mara004, there are 3 things to consider in the case of
|
This comment was marked as outdated.
This comment was marked as outdated.
|
I've now had some more time to look into this, and unfortunately it seems like it is simply not possible to do what I need with a PEP 517 compliant build system. @abravalheri Re-reading your previous comment, I think you might not yet have understood what my setup code really does, so I'll try to explain the project's requirements and the current approach:
This has the following advantages:
The approach of PEP 517 and the deprecation of the
A potential fix to allow cross-packaging again would be to add a
From what I have seen, sdist should automatically take all files in the repository. When I run |
|
Hi @mara004, please find my comments bellow:
When I run: rm -rf dist build src/*.egg-info
python setup.py sdist
tar tf dist/pypdfium2-0.12.0.tar.gzI cannot find the
This statement is incorrect, please check https://setuptools.pypa.io/en/latest/deprecated/distutils/sourcedist.html#specifying-the-files-to-distribute (which also states which files are included by default). I understand that your current workflow has been optimised for years to work with the previous behaviour of setuptools. However the packaging ecosystem for Python has been changing for a while now. There are new standards in place and the setuptools wants to rely on these standards to allow us to remove complexity and be able to focus in other aspects of the implementation. This is one of the reasons why running If you want to keep the way things are current implemented, that is fine too! Both setuptools and pip have a lot of stuff implemented to support legacy packages. But you will have to be aware and workaround the limitations that are implied by that approach. One of them is seeing the warning. You can still get around that by defining a filter via On the other hand, if you want to give it a try to PEP 517, it might be worthy to start with the You can always wrap an existing PEP 517 backends to tweak more deeply how they work for your package. |
That is confusing. I cannot reproduce this behaviour, at least not with the latest state of the repository. When running your sequence of commands, I get a tarball including all directories and files that are not excluded in I'll investigate the other mentioned points and reply in following comments. |
It is not, because it means the code will eventually stop working, should the setuptools comman-line really be removed some day.
The warning is there for a reason. Filtering it won't help anyone. |
Sure, but the current approach of PEP 517 has serious limitations that cause a lot of problems for downstream packagers. |
|
One pratical use case is the future removal of easy_install. |
What pybind does looks interesting, but from what I can see it's not about dealing with pre-built binaries. |
The problem is that this reduction in complexity of the setuptools codebase greatly increases the difficulty for downstream packagers. With the old Another general flaw of PEP 517 is that all projects need to add yet another setup file,
|
|
Hi @mara004, locally I was able to use Of course this does not imply that those artifacts are correct (I am not an user of the project, nor I have knowledge about its code base and tests), in fact they can be completely wrong and just because I managed to get Maybe it might be interesting for you to give it a try and see if the tests run correctly after you install the artifacts built from Regarding PEP 517, I recommend bringing any discussions about its pitfalls and improvement proposals to https://discuss.python.org/c/packaging/14. |
|
That's very interesting, thanks for trying this. Could you please submit a PR so I can take a look? The test suite should be fairly easy to use: Just install the artifact that corresponds to your platform and run In particular, I would like to know how you managed to get |
I don't know how to answer this question. What I really did was just add a How does |
|
Okay, I see. This means your changes do not solve the problem - I already tried your suggestions from #2847 (comment).
Well, this is the procedure that
However, the main point is that
Yeah, but that misses the actual problem. Running the main python3 platform_setup/setup_sdist.py sdist
python3 platform_setup/setup_darwin_x64.py bdist_wheel
python3 platform_setup/setup_darwin_arm64.py bdist_wheel
python3 platform_setup/setup_linux_x64.py bdist_wheel
python3 platform_setup/setup_linux_arm64.py bdist_wheel
python3 platform_setup/setup_linux_arm32.py bdist_wheel
python3 platform_setup/setup_windows_x64.py bdist_wheel
python3 platform_setup/setup_windows_x86.py bdist_wheel
python3 platform_setup/setup_windows_arm64.py bdist_wheel |
|
By the way, I now finally understood the |
This reminds me the way |
How does that work? How can I make |
|
Build will not do that automatically for you. They are |
|
I see..... That's not a bad approach. It might be possible to do something similar for pypdfium2, though it would make the main setup file harder to overview. |
|
@abravalheri I now changed pypdfium2 to use PEP 517 setup with an environment variable to control which code to run. |
|
Hi @mara004, nice to hear that things seem to be working! I think the problem with I imagine a quick and dirty way of doing that is Footnotes |
|
Ah, yes. Sorry, I overlooked you already mentioned this. I will see what I can do with |
|
I think the following piece of code should work: def include_platform_setup():
name = 'platform_setup'
PlatSetupInit = join(dirname(abspath(__file__)), name, '__init__.py')
spec = importlib.util.spec_from_file_location(name, PlatSetupInit)
module = importlib.util.module_from_spec(spec)
sys.modules[name] = module
spec.loader.exec_module(module)with corresponding call of |
setuptools version
setuptools==58.3.0 or setuptools==58.4.0
Python version
Python 3.8
OS
Ubuntu 20.04
Additional environment information
No response
Description
Attempting to install or build a wheel of a project using setuptools results in the following warning:
Full traceback:
This occurs with both build and pip (
pip installandpip wheel).Expected behavior
No warning is emitted when building a wheel or installing using pip or build.
How to Reproduce
PYTHONWARNINGS=error pip wheel domdf_python_tools==3.1.0 --no-binary domdf_python_tools -v --no-depsThis also occurs with
wheyandnatsort.Output
Code of Conduct
The text was updated successfully, but these errors were encountered: