Comments (12)
- Setuptools already overrides/vendors the stdlib distutils and will continue to do so even for Python 3.12 https://setuptools.pypa.io/en/latest/deprecated/distutils-legacy.html#porting-from-distutils
setup.py install
is independent ofdistutils
unless the packagedsetup.py
specifically imports it. Evenpython3 -m build
will be affected from a distutils drop if all it does is to use the setuptools backend as defined in the pyproject.toml which in turn calls setup.py- The fact that setuptools is still the go to backend for many PEP517 builds will never allow us to drop it from Ring 1.
- What's the advantage of a new set of macros over just using
%pyproject_wheel
and%pyproject_install
? Pip is and will continue to be packaged in Ring1 and has a small external dependency footprint.
from python-rpm-macros.
setup.py install
is still deprecated, regardless, so we need to do something.- Never say never, I still remain hopeful that will happen at some point, and Jason does seem to be working towards that goal.
- Pip is enormous and its small external footprint is only because it continues to vendor a lot of other code, which also means it gets a lot more fun to debug issues with calling it.
build
andinstaller
are targetted, and since both are pypa-sponsored, I remain hopeful that pip itself will use them in the future.
from python-rpm-macros.
setup.py install
is still deprecated, regardless, so we need to do something.
Agreed, but the addition macros for build and installer is orthogonal to this something. You have to replace the calls in the packages, either through replacing %python_build
and %python_install
or through redefining them. In almost all python package updates I submitted in the past few weeks, I replaced them with the %pyproject_*
equivalents and added pip and wheel.
- Pip is enormous and its small external footprint is only because it continues to vendor a lot of other code, which also means it gets a lot more fun to debug issues with calling it.
build
andinstaller
are targetted, and since both are pypa-sponsored, I remain hopeful that pip itself will use them in the future.
True, but it is still the de facto standard and supported by 99,9% of upstream packages.
from python-rpm-macros.
I'm bringing this up again because the dependency cycles are getting ridiculous. Sure, we can use pip and the existing macros, but the bootstrapping is awful, and we now have hatchling which is used by a large number of packages unable to build itself because it's now in a build loop with trove-classifiers.
from python-rpm-macros.
If we are talking just about adding yet another macroised way how to build and install Python packages, then I am all for it: more and merrier! It will also mean that build
(and installer
?) get to the Ring0, but hopefully these would be small ones.
from python-rpm-macros.
we now have hatchling which is used by a large number of packages unable to build itself because it's now in a build loop with trove-classifiers.
In what way does this relate to additional macros and the usage of build and installer instead of pip?
from python-rpm-macros.
In what way does this relate to additional macros and the usage of build and installer instead of pip?
Because bootstrapping is a concern here -- pyproject_wheel does not just require pip and everything is golden, hatchling and poetry are also required in larges part of the archive. The build cycle I'm trying to solve is this one:
Cycles for x86_64 (#4)
python-hatch_vcs, python-hatchling, python-iniconfig, python-trove-classifiers
build and installer can be bootstrapped by flit_core, which means I'd prefer to switch these packages in particular to using the new macros, if we are in agreement.
from python-rpm-macros.
Still, the bootstrap problem is independent of the the question whether you use build
or pip
as PEP517 frontend.
from python-rpm-macros.
You still seem against adding a macro, so do I close this, or continue arguing?
from python-rpm-macros.
I am mainly against conflating two totally different issues.
- It does not solve the dependency cycle problem
- More macros means more complexity for packagers: How to decide which one to use?
- Does adding yet another macro group add any benefit?
- What's the advantage over replacing pip in
%pyproject_wheel
and%pyproject_install
? - Compare Fedora: The still use
pip
in pyproject-rpm-macros
from python-rpm-macros.
What's the advantage over replacing pip in
%pyproject_wheel
and%pyproject_install
?
A little +1 from me here. We don’t say %pip_build
here, so theoretically it should not matter what tools we use behind the curtains. Yes, complete rebuild of Factory with new macro will be … interesting … but it seems to me like that it is doing the right thing, instead of just the easy one.
from python-rpm-macros.
We already have 2 macros for building and installing and 3 macros for testing. But I'm done arguing.
from python-rpm-macros.
Related Issues (20)
- Breaks builds (e.g., tex(symbol) is split) HOT 2
- Request to bring %python_compileall to python-rpm-macros HOT 7
- rpmlint is not happy with the current libalternatives handling HOT 2
- Error in libalternatives filelist produced by the %python_alternative macro HOT 1
- export PYTHONPATH and --import-mode=append required for successful python builds HOT 7
- Shouldn’t %primary_interpreter be part of the OBS project rather than in the SPEC file? HOT 7
- Missing {} around parameter in _python_sysconfig_path/var macros HOT 1
- Old "py_requires" macro for python2 fails to expand properly on Leap 15.4 HOT 2
- libalternatives handling wrong HOT 3
- Additional flags in scriptlets (like `%pre -f`) HOT 21
- %pyproject_wheel doesn't work without %python_subpackages HOT 2
- Cannot add `--install-options` to %pyproject_install HOT 4
- Add python312 in <flavor> HOT 2
- python_compileall fails to strip the buildroot HOT 16
- Conditionally switch off providing python3-* packages for primary set HOT 16
- rewrite shebangs for "pythons python3" packages HOT 1
- Better support reproducible builds HOT 18
- _pyproject_wheeldir of "build" is way too generic HOT 15
- pip --build-option is deprecated HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from python-rpm-macros.