Turn zope.meta into a real installable Python package

[dataflake]

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.

[mgedmin]

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.

[mauritsvanrees]

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.

[icemac]

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.

[icemac]

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]

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]

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]

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

[dataflake]

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]

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

[mauritsvanrees]

Thanks a lot!

[icemac]

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

[dataflake]

Thanks!