Hey hey,
Thomas has already answered a lot... but here anyway.
1) online documentation, and pip installable helps a lot.
But also letting people know your lib exists is helpful.
Especially examples online (not just in a folder), and
little tutorials help people a lot.
It could be good if we set up a wiki page on the pygame
website with 'awesome pygame libraries'.
Also might be nice if we could contribute to each others
stuff more easily.
There's quite a few libraries which cover the same
functionality implemented by different people again and again.
If you wanted to, we could host your library on the
pygame github organisation. The offer is there anyway.
(Also, the offer is there for other mature widely used
pygame related libraries)
- more visibility
- slightly easier collaboration
3) python packaging guide is the best we have currently.
For pure python libraries it's not the worst.
4) pypi allows you to host documentation on there for free
(on pythonhosted).
The python packaging guide doesn't mention documentation.
(Which is a pretty major missing piece that probably
deserves an issue raised.
(The benefit of python hosted over read the docs, is they
don't inflict advertising on your users like read the docs
does.)
(Or do you have your own website library?
Then you can set a CI hook to upload the docs when
merging to default branch)
Use Sphinx (it's by far the best documentation tool for
python these days).
4 a) I've recently discovered you can include examples
more easily now in the docs. So you can include an example
file, and line ranges.
4 b) documenting your param args and types is useful for
docs, and for things like command line completion in IDEs.
(Another improvement for the pygame docs that could be
done if only someone had time.)
5) Projects which break things up into lots of smaller
parts often do things in the one repo.
This makes it much easier to do.
However, since python packaging is still quite a lot of
work, I'd suggest not doing this.
6) cool. Yeah, such generation tools can help with
packaging. But then you have to maintain the generated code.
7) keep configuration as minimal as possible.
There's the packaging guide of course,
Whilst not the cleanest, I think following that is
probably a good idea at this exact moment in time.
8) I think many of the distribution tools support packages these
days.
Virtualenvs are the way to go at the moment to avoid
version conflicts. That's the best we have.
Keeping a stable API if possible is hard, but also lets you
install things system wide, and have less troubles.
9) stable API, and backwards compatibility helps the most
with this.
Which also helps your users programs. But it's harder work
coming up with stable APIs.
10) You can do tools (scripts) with entry points like this:
Feel free to ask if you get stuck with anything, or if
you want someone to review your docs/website.
Both Thomas and I have quite the packaging quirks
knowledge having battled with it a lot (unfortunately).
(as do others on the list of course)
I'd like to help more, but I guess I'm fairly thinly
stretched already with pygame stuff already.
Perhaps there's somehow a way to give more visibility on
the pygame website for 'awesome' libraries. If someone has
a good idea, PR's accepted, and of course I'd make that a
priority for my pygame time.