-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moved the metadata into setup.cfg #253
Conversation
f15865c
to
aa1bca1
Compare
6a25aa4
to
0caff24
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I support shifting towards newer packaging systems but can you elaborate (maybe update the doc section) what is the intended way of archive generation after this set of changes (see inline comments)?
setup.py
Outdated
@@ -1,4 +1,4 @@ | |||
#! /usr/bin/env python | |||
#! /usr/bin/env python3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, I don't think python2 ca be dropped out of the equation yet. I let a maintainer confirm.
Is python2 fully incompatible with this set of changes or the update to py3 comes for a convenience?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't remember. I remember that the version of setuptools released in January 2020 has dropped python 2. I don't use python 2 since 2013.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not everyone is that lucky ...
setup.py
Outdated
|
||
setup( | ||
name = 'securesystemslib', | ||
version = '0.18.0', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested locally with python 3.7 generating a source dist as it is still listed in the documentation:
$ python setup.py sdist
The resulting archive is missing a version number: securesystemslib-0.0.0. I assume this may be some incompatibility with setuptools_scm
?
In case I was not supposed to use setup.py
to generate the sdist, what is the intended way of archive generation after this set of changes? Using the pep517
module as shown in the PR description did the job but the package documentation marks its high-level functionality as deprecated.
Seems like the recommended way is by using build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Try to upgrade setuptools. You need a recent (at least January 2019) setuptools to understand pyproject.toml, and if it understands it, it would upgrade itself to the version having the needed hooks setuptools_scm
that uses pyproject.toml
for config depends on.
Seems like the recommended way is by using
build
.
Yes, it's true. The PR was originally created when there was no build
.
d1b7625
to
feccb33
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the persistence and sorry for the late review, @KOLANICH!
Let me know if you feel like switching to hatchling
in this PR. I'm also fine if we do that in a follow-up PR. I wouldn't add setuptools_scm
, though, as we didn't use it before and won't use in the future.
pyproject.toml
Outdated
dependencies = [ | ||
"six>=1.11.0", | ||
'subprocess32; python_version < "3"', | ||
"python-dateutil>=2.8.0", | ||
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dependencies = [ | |
"six>=1.11.0", | |
'subprocess32; python_version < "3"', | |
"python-dateutil>=2.8.0", | |
] |
We don't have any of these dependencies anymore.
pyproject.toml
Outdated
[project.optional-dependencies] | ||
crypto = ["cryptography>=37.0.0"] | ||
pynacl = ["pynacl>1.2.0"] | ||
testing = ['mock; python_version < "3.3"'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
testing = ['mock; python_version < "3.3"'] |
Don't need this one anymore either.
@@ -0,0 +1,63 @@ | |||
[build-system] | |||
requires = ["setuptools>=61.2", "setuptools_scm[toml]>=3.4.3"] | |||
build-backend = "setuptools.build_meta" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need the features of setuptools_scm
, and I'd generally like us to switch to hatchling
as we did in python-tuf and in-toto (theupdateframework/python-tuf#1896, in-toto/in-toto#490).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current PR does use setuptools_scm magic to build the package version number (it's not anywhere in source right now). Otherwise I think you are correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right, I forgot that we don't have the version in __init__.py
. I'd rather add it there and not use git to infer it. But I'm fine with doing that in a follow up PR.
pyproject.toml
Outdated
PySPX = ["PySPX==0.5.0"] | ||
|
||
[tool.setuptools] | ||
include-package-data = false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this relate to MANIFEST.in? I think we want to include some non-*.py files in source distributions.
I'd prefer it to happen in a separate PR/commit. Switching to
As
It may be possible to make
When it is |
Agreed. Let's switch to hatchling in a follow-up PR.
Okay, let's use
Don't know how to do it in
Thanks for the docs link. I suggest to either set it to true then or replicate the includes/excludes from MANIFEST.in here and remove MANIFEST.in. |
I see you force-pushed but did not address my review comments. Are you interested in finalizing this PR, @KOLANICH? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! I tried this and it works as expected.
Also checked that it includes everything we want it to include in an sdist via MANIFEST.in. Interestingly, it also includes at least one of the files we ignore via the manifest.
No need to fix this here, as we need to change the configuration when switching to hatchling anyways.
Thanks again for the contribution, @KOLANICH!
Please fill in the fields below to submit a pull request. The more information
that is provided, the better.
Fixes issue #:
Description of the changes being introduced by the pull request:
setup.cfg
is a declarative format for metadata requiring no remote code execution in order to be parsed.setuptools_scm
fetches versions from git tags, which decreises new release burden. For non-tag commits it adds pat of a commit hash to a version, which helps bug reporting if anything goes wrong.pyproject.toml
is a newer declarative format for configuration. In some distant futuresetup.cfg
contents will be moved there. Tools recently introduced declarative configuration, likesetuptools_scm
, use it. It also allows to build packages in an unified way:python3 -m pep517.build -b
Please verify and check that the pull request fulfils the following
requirements: