Skip to content
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

refactor: attempt to modernise build #294

Merged
merged 6 commits into from
Mar 13, 2023
Merged

refactor: attempt to modernise build #294

merged 6 commits into from
Mar 13, 2023

Conversation

grawlinson
Copy link
Contributor

First attempt at fixing issue #290.

Copy link
Collaborator

@TomasTomecek TomasTomecek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect! Just one question about the build frontend and we're good to merge

also please rebase to get changes from #293

pyproject.toml Outdated Show resolved Hide resolved
@TomasTomecek
Copy link
Collaborator

Also please suggest how to obtain current version, that's what the build error is:

2023-02-07 08:31:57.646 base_git.py       INFO   Using user-defined script for ActionName.get_current_version: [['python3', 'setup.py', '--version']]
2023-02-07 08:31:57.646 commands.py       DEBUG  Command: python3 setup.py --version
2023-02-07 08:31:57.660 logging.py        INFO   python3: can't open file '/tmp/tmpsarfl_k2/setup.py': [Errno 2] No such file or directory
2023-02-07 08:31:57.663 commands.py       ERROR  Command 'python3 setup.py --version' failed.
2023-02-07 08:31:57.663 commands.py       DEBUG  Command stderr: python3: can't open file '/tmp/tmpsarfl_k2/setup.py': [Errno 2] No such file or directory

I'm happy to fix that and push to your branch if you don't want to mess with RPM packaging 😁

@grawlinson
Copy link
Contributor Author

Also please suggest how to obtain current version, that's what the build error is:

2023-02-07 08:31:57.646 base_git.py       INFO   Using user-defined script for ActionName.get_current_version: [['python3', 'setup.py', '--version']]
2023-02-07 08:31:57.646 commands.py       DEBUG  Command: python3 setup.py --version
2023-02-07 08:31:57.660 logging.py        INFO   python3: can't open file '/tmp/tmpsarfl_k2/setup.py': [Errno 2] No such file or directory
2023-02-07 08:31:57.663 commands.py       ERROR  Command 'python3 setup.py --version' failed.
2023-02-07 08:31:57.663 commands.py       DEBUG  Command stderr: python3: can't open file '/tmp/tmpsarfl_k2/setup.py': [Errno 2] No such file or directory

I'm happy to fix that and push to your branch if you don't want to mess with RPM packaging 😁

That would be great!

I’m off on holiday for a few days, so I won’t be able to do much until I get back.

First attempt at fixing issue #290.
@TomasTomecek
Copy link
Collaborator

@grawlinson LGTM from my side, enjoy your vacation!

once you're back, let me know if you'd like to do more changes here

pyproject.toml Outdated
# setuptools: https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html
# setuptools-scm: https://github.com/pypa/setuptools_scm/#pyprojecttoml-usage
[build-system]
requires = ["setuptools>=61", "setuptools-scm[toml]>=6.2", "wheel"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just tested this PR locally in a fedora:36 container and it worked fine with python3-setuptools-59.6.0-3.fc36.noarch so I'm thinking that maybe we don't need to pin the version of setuptools

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fascinating, even works with a very old setuptools - python3-setuptools-53.0.0-12.el9.noarch

I suspect it's because build creates a venv and installs new setuptools inside: sadly the output doesn't say which versions

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, build creates its own env but you can pass a CLI option to prevent it from managing the env.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that ancient setuptools wouldn't know how to read pyproject.toml.

.packit.yaml Outdated Show resolved Hide resolved
.packit.yaml Outdated
get-current-version:
- "python3 setup.py --version"
- "python3 -m setuptools_scm"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may need piping through awk because it may output extra text.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, that's possible and it already happened: the build fails then and needs investigation

pyproject.toml Outdated Show resolved Hide resolved
pyproject.toml Outdated
# setuptools: https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html
# setuptools-scm: https://github.com/pypa/setuptools_scm/#pyprojecttoml-usage
[build-system]
requires = ["setuptools>=61", "setuptools-scm[toml]>=6.2", "wheel"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that wheel is not needed here. Setuptools adds it for wheel builds automatically.

Suggested change
requires = ["setuptools>=61", "setuptools-scm[toml]>=6.2", "wheel"]
requires = ["setuptools>=61", "setuptools-scm[toml]>=6.2"]

pyproject.toml Outdated
# setuptools: https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html
# setuptools-scm: https://github.com/pypa/setuptools_scm/#pyprojecttoml-usage
[build-system]
requires = ["setuptools>=61", "setuptools-scm[toml]>=6.2", "wheel"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, build creates its own env but you can pass a CLI option to prevent it from managing the env.

pyproject.toml Outdated
# setuptools: https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html
# setuptools-scm: https://github.com/pypa/setuptools_scm/#pyprojecttoml-usage
[build-system]
requires = ["setuptools>=61", "setuptools-scm[toml]>=6.2", "wheel"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that ancient setuptools wouldn't know how to read pyproject.toml.

Copy link
Member

@webknjaz webknjaz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I forgot another important bit: for setuptools-scm to work properly with downloads from GitHub, you must update .git_archival.txt. See their readme for details, it's pretty straightforward.

* use setuptools_scm directly to get version

* use python3-build to create dists

Signed-off-by: Tomas Tomecek <[email protected]>
@TomasTomecek
Copy link
Collaborator

Oh, I forgot another important bit: for setuptools-scm to work properly with downloads from GitHub, you must update .git_archival.txt. See their readme for details, it's pretty straightforward.

just checked and we already have that set up :)

@webknjaz
Copy link
Member

just checked and we already have that set up :)

@TomasTomecek the file exists but the contents are outdated — there's a newer "match" bit still missing.

@TomasTomecek
Copy link
Collaborator

@webknjaz you're correct. I just checked what the option does exactly - luckily it's easy to play with:

The usual tags we have here:

$ git describe --tags --dirty --long --match="*[0-9]*"
0.10.1-6-g8166839

$ git describe --tags --dirty --long
0.10.1-6-g8166839

Let's do an "ugly" tag:

$ git tag foo-bar

$ git describe --tags --dirty --long
foo-bar-0-g8166839

$ git describe --tags --dirty --long --match="*[0-9]*"
0.10.1-6-g8166839

So the match option prevents weird versions from weird tags.

I don't think we need that option but agreed it could prevent odd behaviour in the future. Let's apply it if no one objects.

@webknjaz
Copy link
Member

Those updates will only work with modern Git, they'll allow installing from non-tagged commits and getting proper intermediate versions.

new recomentation from setuptools_scm

thanks @webknjaz

Signed-off-by: Tomas Tomecek <[email protected]>
@webknjaz says setuptools adds it automatically

Signed-off-by: Tomas Tomecek <[email protected]>
@TomasTomecek
Copy link
Collaborator

I implemented the last bits of feedback. Let's merge after all's green.

@TomasTomecek
Copy link
Collaborator

the failing test is a network DNS flake, merging

@TomasTomecek TomasTomecek merged commit 692618c into ansible-community:master Mar 13, 2023
@gotmax23
Copy link
Contributor

This breaks compatibility with EL 9 and Fedora 36.

@gotmax23
Copy link
Contributor

I'd recommend implementing this in the same way we did for specfile. Remove the setup.py, keep the metadata in setup.cfg sans setup_requires, and add a minimal pyproject.toml.

@TomasTomecek
Copy link
Collaborator

I'm not concerned about EL9 since there are no EPEL9 builds: https://src.fedoraproject.org/rpms/ansible-bender

Folks installing from PyPI can upgrade their setuptools.

Similarly F36, gonna be EOL within 2 months.

It will take a long time before this gets released given my velocity of a sloth.

Nevertheless, I'm okay changing the python packaging as long as it works.

@gotmax23
Copy link
Contributor

I've submitted #296. @webknjaz and @grawlinson, feel free to take a look as well :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants