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.
2) Bitbucket has free CI built in these days.
https://confluence.atlassian.com/bitbucket/python-with-bitbucket-pipelines-873891271.html
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.
https://packaging.python.org/
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.
https://github.com/pypa/python-packaging-user-guide/issues/484)
(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).
http://www.sphinx-doc.org/en/master/
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.
https://thomas-cokelaer.info/tutorials/sphinx/docstring_python.html
(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,
and this 'official' example project. https://github.com/pypa/sampleproject
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:
https://packaging.python.org/tutorials/distributing-packages/?highlight=console_scripts#entry-points
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.
cheers,
On Mon, May 7, 2018 at 9:06 PM, DR0ID <dr...@bluewin.ch
<mailto:dr...@bluewin.ch>> wrote:
Hi René and others
Now after pyweek 25 I have some time to improve my libs.
I would need a little help (I know, its not directly pygame
related and if you want to redirect me to the python list I'll be
fine with it):
[1] What would be your suggestions to make the stuff more useful?
[2] Any tips on (free) CI builds?
[3] Any tips on packaging for pip?
[4] Any tips for the documentation?
[5] Would you break up libs into smaller, maybe partial parts that
are pip installable so they can be installed independently? If so,
should each have its own repo or not (keeping it in the same repo
in sub directories)?
[6] Might need some improvements, but some time ago I made this
and tried to use it everywhere:
https://bitbucket.org/dr0id/cookiecutter-pypackage-hg/src/default/
<https://bitbucket.org/dr0id/cookiecutter-pypackage-hg/src/default/>
[7] Any hints for best-practices?
[8] One thing that has bothered me along time and I have not found
any good answer yet is following: pip installable packages are
good for developers while coding and developing. But then, when I
want to 'ship' or 'distribute' some program I'm not so sure that
is the way to go. Because I think there should be a distinction
between a library (that you install in site-packages) and a
'executable' which I might want to install somewhere else
(otherwise I would not know hot to run it, maybe using '-m'?).
[9] Also there is the trouble with versions of the libs (I know,
use virtualenv, but that seems laborious) if to 'programs' need
different versions of the same lib. So one way around this is to
ship all the needed libs with the program (so no imports from
site-packages used).
[10] This trouble is visible in some of my libs because sometimes
I have the lib and some 'tools' for it and it seems to me that the
tools should not go into site-packages. But maybe I got it all
wrong or don't know best practices for python programs. Maybe
someone can point me to a tutorial or help clarify those points.
~DR0ID
On 07.04.2018 10:29, René Dudfield wrote:
There's several tons of useful and awesome stuff in there DR0ID!
I guess you know this already... but... hosting the documentation
somewhere would make it a bit easier to get into. (as would
making it pip installable).
It looks like you did at some point.
On Fri, Apr 6, 2018 at 8:40 PM, DR0ID <dr...@bluewin.ch
<mailto:dr...@bluewin.ch>> wrote:
On 06.04.2018 18:12, Leif Theden wrote:
Ahem. I'll shill more of my libraries:
https://github.com/bitcraft/animation
<https://github.com/bitcraft/animation>
Tasks and tweening using pygame groups. No framework needed
to have things execute over time.
On Thu, Apr 5, 2018 at 8:39 AM, Martin Kühne
<mysat...@gmail.com <mailto:mysat...@gmail.com>> wrote:
On Thu, Apr 5, 2018 at 2:40 PM, Yann Thorimbert
<yann.thorimb...@unige.ch
<mailto:yann.thorimb...@unige.ch>> wrote:
> Not exactly awesome,
Come again? What ridiculous standard are you assuming
there for "awesome"?
cheers!
mar77i
Hi
here my awsome libs for pygame:
- hierarchial state machine:
https://bitbucket.org/dr0id/symplehfsm/overview
<https://bitbucket.org/dr0id/symplehfsm/overview>
- loading sprite sheets (it can load any shapes, but usage is
a bit cumbersome, needs an update):
https://bitbucket.org/dr0id/spritesheetlib
<https://bitbucket.org/dr0id/spritesheetlib>
- collection of useful tools (tweening, animation, context,
timing, fonts, spritesystem, skeleton, ...) for games (used
mostly in pyweeks): https://bitbucket.org/dr0id/pyknic
<https://bitbucket.org/dr0id/pyknic>
- tmx loader: https://bitbucket.org/dr0id/pytmxloader
<https://bitbucket.org/dr0id/pytmxloader>
None of them is pip installable so I recommend to copy them
into your project and use them from there. Maybe someone find
any of this useful. Contribution and suggestions are welcome.
~DR0ID
