-
Notifications
You must be signed in to change notification settings - Fork 6
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
Conversation
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.
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.
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 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.
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 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.
You mean we could even make our repos self-updating. This is a really interesting idea. 😀 |
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. |
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. |
I suppose the repo could keep its |
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. |
To finally get this off the ground I will retain the repository name and changed the documentation and configurations to make this work. |
Thanks a lot! |
@dataflake Thank you for your work on this ticket, I really like the outcome! |
Thanks! |
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.