https://pantsbuild.org/ logo
Join Slack
Powered by
Oh. I see the docs say "building distributions, wh...
# general
p
Oh. I see the docs say "building distributions, whether via PEP 517 config, or directly via legacy support. If using Setuptools in either fashion, you need a 
setup.py
script alongside your 
python_distribution
target" I guess I need to get a generated setup.py after all. Isn't there a way to use Setuptools without a setup.py?
h
I'm not sure that doc is correct. With pep517/518 support you should be able to use any backend in any way it can be used
If pep517 allows setuptools to be used without a setup.py (say with just a pyproject.toml and setup.cfg) then this should work
You would set
Copy code
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"
In pyproject.toml
and make sure all the deps were set up so that setup.cfg and pyproject.toml are deps of the python_distribution target
and it should work
if it doesn't, it's a bug
p
You don't need setup.cfg - everything can be defined in pyproject.toml now under 
[project]
. But, 
python_distribution
requires 
provides=
but I don't want to define 
python_artifact
if all that data is in pyproject.toml. So, I see two directions this could work better: • 
python_project
instead of 
python_artifact
, but pull the details from pyproject.toml instead of kwargs • Pants could generate a pyproject.toml (or extend an existing one) with a 
[project]
section based on the kwargs of 
python_artifact
Generating pyproject.toml would be very interesting in StackStorm because I still want to centrally define a lot of the metadata for all the distributions. I'm very interested in moving away from setup.py eventually so that anything interested in a wheel's metadata (like on pypi) does not need to run setup.py.
h
Ah, right, you do need provides=, but that is the only thing you need
And that is not used for generating a setup.py (which you wouldn't be doing) but so Pants knows what it's publishing, in case it needs to infer requirements on that thing in some other published wheel
And in fact we could probably relax that insistence on provides=, if you aren't using generated setup.py at all then we aren't generating requirements metadata in other wheels on this wheel, so it seems wrong to insist
c
h
So basically you should be fine with invoking setuptools via pep517 in the non-legacy way, without a setup.py
generated or otherwise
if that doesn't work, I'd consider that a bug
p
OK. after several tries, I figured out that I have to include both 
setuptools
and 
wheel
in my 
[build-system].requires
list. Otherwise I get errors about 
error: invalid command 'bdist_wheel'
. So, I’ve got my metadata in pyproject.toml, with 
generate_setup = False
on my 
python_distribution
which is working. But none of the metadata from 
[project]
is making it into my wheel. Turns out I have to have setuptools 61+ to use that. So, now I’m working on updating my build-system.requires to make that work…
And I can’t use setuptools 61 because I need to target python 3.6 and it only supports 3.7+. OK. well that was fun.
I shall revert back to using setup.py
So, not a pants bug in this case, just me not understanding something new to me. 🙂
h
The Scylla and Charybdis of python packaging right here
Open in Slack
PreviousNext
Powered by