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

Turn zope.meta into a real installable Python package #282

Merged
merged 20 commits into from
Oct 2, 2024

Conversation

dataflake
Copy link
Member

@dataflake dataflake commented Sep 27, 2024

This PR turns zope.meta into a real Python package that can be installed like any other package. The scripts were changed slightly so they can be used as a console script entry point and the README was updated accordingly.

At the same time the packaging also allows running the zope.meta scripts against zope.meta itself, the results are also part of this PR.

My main goal is script re-use for custom applications. I would like to be able to create a simple script (or simple package) where I can import zope.meta code and override settings, like loading file templates from a different path or applying different settings from the zopefoundation defaults. This PR is just a first step towards that goal.

Fixes #97.

@dataflake dataflake added the enhancement New feature or request label Sep 27, 2024
@dataflake dataflake self-assigned this Sep 27, 2024
Copy link
Member

@mgedmin mgedmin left a comment

Choose a reason for hiding this comment

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

Mostly LGTM! Also, this PR makes me happy.

One script needs a bit more code to be moved inside main() so it won't do command-line argument parsing at run time.

The lack of actual tests makes me wonder about the utility of the tox.ini and docs/hacking.rst. I think we should at least add an empty-ish tests.py so that anyone who wants to add a test will have a lower threshold of entry. I don't think this PR needs to be blocked until we have actual tests -- as long as CI doesn't fail trying to enforce the 85% of coverage or whatever it has configured by default.

I would also like confirmation that all the references to github.com/zopefoundation/zope.meta are intentional and you plan to rename the repository. I think GitHub will provide automatic redirection for people who use the old URL/have old git clones.

pyproject.toml Outdated Show resolved Hide resolved
CHANGES.rst Show resolved Hide resolved
docs/hacking.rst Outdated Show resolved Hide resolved
docs/hacking.rst Outdated Show resolved Hide resolved
docs/hacking.rst Outdated Show resolved Hide resolved
setup.py Outdated Show resolved Hide resolved
src/zope/meta/multi_call.py Outdated Show resolved Hide resolved
setup.py Show resolved Hide resolved
docs/hacking.rst Outdated Show resolved Hide resolved
docs/hacking.rst Outdated Show resolved Hide resolved
setup.py Outdated Show resolved Hide resolved
Copy link
Member

@mauritsvanrees mauritsvanrees left a comment

Choose a reason for hiding this comment

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

I did not try it, but the idea seems good, making it easier to apply zope/meta on a package without needing to have a git checkout of it.

This would even make it possible to add a scheduled GitHub workflow action that installs zope.meta and runs it on the repo and see if anything has changed.

Copy link
Member

@icemac icemac left a comment

Choose a reason for hiding this comment

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

I really like the idea and admire the time you invested into this change. I already used meta/config for some OSS projects outside the ZF and making reuse easier will be a great win.

Though I have some hopefully helpful questions.

.pre-commit-config.yaml Outdated Show resolved Hide resolved
docs/_static/.gitignore Outdated Show resolved Hide resolved
docs/hacking.rst Outdated Show resolved Hide resolved
docs/hacking.rst Outdated Show resolved Hide resolved
setup.py Show resolved Hide resolved
@icemac
Copy link
Member

icemac commented Oct 2, 2024

This would even make it possible to add a scheduled GitHub workflow action that installs zope.meta and runs it on the repo and see if anything has changed.

You mean we could even make our repos self-updating. This is a really interesting idea. 😀

@dataflake
Copy link
Member Author

I am not totally convinced about the renaming: In the archived packages we point to https://github.com/zopefoundation/meta to request unarchival. So maybe the code might go to zope.meta but the issues should stay in meta. Do you think this is reasonable and possible?

I am very surprised that you consider a potentially broken link in archived packages in any way important. I disagree and don't think that is important at all. Those are by definition outdated and abandoned.

I don't think it is reasonable and renaming a repository does not allow for keeping the issue tracker in the old place.

@dataflake
Copy link
Member Author

This would even make it possible to add a scheduled GitHub workflow action that installs zope.meta and runs it on the repo and see if anything has changed.

You mean we could even make our repos self-updating. This is a really interesting idea. 😀

I am scared of this. Please don't. That would mean even the smallest and safest commit now risks a broken package and extra work because some of those pre-commit hooks go red.

@mauritsvanrees
Copy link
Member

I suppose the repo could keep its meta name even when setup.py says zope.meta.

@dataflake
Copy link
Member Author

I suppose the repo could keep its meta name even when setup.py says zope.meta.

That would also mean we have another strange one-off, in this case with a package name/repository name mismatch. I'd prefer avoiding that.

@dataflake
Copy link
Member Author

To finally get this off the ground I will retain the repository name and changed the documentation and configurations to make this work.

@dataflake dataflake merged commit 568f275 into master Oct 2, 2024
13 checks passed
@dataflake dataflake deleted the dataflake/zope-meta-package branch October 2, 2024 08:47
@mauritsvanrees
Copy link
Member

Thanks a lot!

@icemac
Copy link
Member

icemac commented Oct 16, 2024

@dataflake Thank you for your work on this ticket, I really like the outcome!

@dataflake
Copy link
Member Author

Thanks!

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

Successfully merging this pull request may close these issues.

RFE: packagize the metaconfiguration script
5 participants