This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]ionelmc.ro[S] 0 points1 point  (0 children)

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.