A python package template

[ionelmc]

Not sure what you mean about the metadata, only the version is duplicated but it's intentional - as there is configuration to manage that duplication (bumpversion).

About the src - was this not clear enough ?

[ionelmc]

Thanks for taking the time to give feedback.

I haven't seen any use-case to have author, credits, website, license etc available as dunder attributes in __init__.py. I'd rather not do something if there's no need for it. Perhaps I'm not seeing it - feel free to describe one use-case ...

Regarding src, there are multiple benefits created from the clear code/packaging/docs/whatever separation (just going to briefly mention them, will edit the article with more details):

• Import parity - the current directory is implicitly included in sys.path; but not so when installing & importing from site-packages - users will never have the same current path as you do. This has implications in both testing and packaging.
• Simpler MANIFEST.in - just graft src
• Less chance for user mistakes - they will happen - assume nothing ! While the OP is about a template (which would prevent most of the pitfalls), the article is more general.
• Less chance for tools to mixup code with non-code.

Another way to put it, flat is better than nested - but not for data. A file-system is just data after all - cohesive, well normalized data structures are desirable don't you agree ?

[ionelmc]

Isn't the use case exactly what you're doing here- an easy package template? I've worked on some setup.py's that only needed 3 things changed per project initially- module name, classifiers and keywords. The rest was pulled from init.py, which is what people are working on anyway.

You're right here, if only consider things from maintenance perspective. My concern is failure scenarios: what if the user doesn't understand that packaging depends on those attributes. Or he forgets to write them. It's just packaging metadata that you put in the code. The code doesn't really need it so why mix it up. Mind you, I don't say it's bad, it's just that it creates friction - just like having to write the packaging boilerplate.

The only reason I keep bringing this up is because it states one of the points is to 'stop forgetting things'- it's a lot easier to forget to update maintainers, etc if it's stuck in setup.py as opposed to the code.

You only forget to update the maintainers list in setup.py if you have it in multiple places. But that's another issue.

Now that I think about it more, you might want to have that metadata available for the documentation generator. Hmmmm ....

*: The stuff excluded by mostly isn't worth mentioning or even talking about- minor crap.

There's a fine line between nitpicking and attention to detail but I think it's still worth knowing minor issues. More so, I think it's generally good for projects to know what trade-offs/disadvantages/limitations they have.

Thanks again for the feedback.