making apps, making webs.

Sick of config file soup cluttering up your repo? Me too. However there is a way to at least clean it up for many python tools. Some of the tools you might use and the config files they support... flake8 - .flake8 , setup.cfg , tox.ini , and config/flake8 on Windows pytest - pytest.ini , tox.ini , setup.cfg coverage.py - .coveragerc , setup.cfg , tox.ini mypy - setup.cfg , mypy.ini tox - tox.ini  Can mypy use setup.cfg as well? OK, you've convinced me. -- Guido With that mypy now also supports setup.cfg, and we can all remove many more config files. The rules for precedence are easy: read --config-file option - if it's incorrect, exit read [tool].ini - if correct, stop read setup.cfg   How to config with setup.cfg? Here's a list to the configuration documentation for setup.cfg. coverage config pytest config flake8 config mypy config behave What does a setup.cfg look like now? Here's an example setup.cfg for you with various too...

Gradual Packaging - allow packaging simple python code with very little effort. Later on (if needed) you can create a more polished package. Follow conventions, support the simple cases. If you need to go out of the simple cases, allow a path towards better packaging. Evolution of your python code. in your ipython session messing around. paste it into badnamechoice.py -> ( everything starts with a bad name in a single .py file ) test_badnamechoice.py -> ( then you add a test. Or did you do this first? ) renamed.py -> ( now you rename the file to something better ) afolderoffiles/ -> ( now there is a folder of files ) add docs/ and .travisci CI files configure coverage testing configure an annoying mypy static type checking option add flakes testing config tweak support some weird debian derived distro appveyor CI added next to travisci pytest config ( change because... ARG reasons) . add a requirements.txt, and modify your setup file to have them too. rem...

In part zero of this series, I pontificated on, " What would python packaging zero look like? " A zero'd package contains just code(and data). Nothing else. Code readability is important. Code changeability is important. These two things have always been a core part of what makes python good. However, the current python packaging world fails on both counts. It's actually pretty damn good overall though (binary wheels for most platforms, a resilient CDN, cached packages, dependency management, enhancement peps are being written, there's now a pypa organisation on github where people collaborate on code together... all good stuff). However, having 10-40 config files in your repo is not readable , nor easily changeable. Which are the files that matter? Generating files from a template is not changeable. Django, rails, cookiecutter, sampleproject - they all generate dozens of files for your project from a template. But when you want to change these fil...

Zero all the things time. Sick of needing 40 files in a python repo to release some code into the world? Me too. How do we fix that? In the spirit of the zero all the things movement... this is an exploration of that question. Say we have our one file "leftpad.py" filled with our high tech left pad implementation. How to share that with people? leftpad.py """Left pad takes a string, and pads it to the left. With such advanced technology, after much research we bla blabl blabla lorem ipsum bla bla. More nonsense which describes more stuff in full. """ def leftpad(s, width, fillchar):     """Return the string right justified in a string of length width. Padding is done using the specified fillchar (default is an ASCII space). The original string is returned if width is less than or equal to len(s).     """     return s.rjust(width, fillchar) We git commit -m "Added advanced left pad function...

This is part three of a series of articles about packaging python games. Part one , Part two . More discussion is happening on the pygame mailing list. TLDR; I think we should follow the python conventions and fix the problems they cause. src, gamelib, and mygamepackage 1). One thing that is different in the skellington layout from the sampleproject one is that the naming is a bit more specific for where the code goes in skellington. Skellington layout: gamelib/ data/ Why this is good? Because you can start writing your code without first having to decide the name. It's a small thing, but in the context of game competitions it's more important. I'm not sure if it's really worth keeping that idea though. Sampleproject layout after doing " skellington create mygamepackage" mygamepackage/ data/ (Where skellington is the name of our tool. It could be pygame create... or whatever) The benefits of this are that you can go i...

This article is part 2 in a series about improving python game distribution. In part one I suggested that python games should be packaged as python packages . Part three is about where the code & data things are . More discussion is happening on the pygame mailing list. Making apps for platforms more easily. Android, windows, mac installers, pip wheels, snappy... the list of platforms goes on. All that is quite time consuming to setup. So how do we make this easier? Have a standard package layout, and build tools which work on that layout. The Python Packaging Authority has put out a git repo with a basic python package. I think we should create one based on that and use it for the 'skellington' that pyweek uses. Skellington is 'base code', or boilerplate code used in the pyweek competitions. It makes doing things like creating windows .exe files, and such easy. Because it does all of the work to configure things correctly. If we have a standard package ...

This is a statement of intent similar to what I wrote to the pygame mailing list some weeks ago. That I think the python game community should promote packaging their games as python packages. When I wrote to the mailing list, not everyone was convinced, and some people had other ideas. So I'm going incorporate their feedback, and to try to be more detailed on the full plan of where I think we should go, what benefits this provides the python community as a whole, and the benefits it provides game developers. This is the first in a series of articles about making python game distribution better. “ the python game community should use python packages ” With all the great work from lots of people pygame is often easily installable via pip - the standard python packaging system. We still have some issues, but it works quite well on major platforms. See " How we cobbled together a free Spectacularly Adequate Build Page. " for more details on how we package pygame...

Integrated modules are nice, but so are modular packages. How can we have both? That is, keep all things for a module(or sub package) in one directory, but also have a nice integrated system built on top of that? Often for one package I will have a file layout like so: /setup.py /[package_name] /[package_name]/[package_module].py /[package_name]/tests/[package_module]_test.py /[package_name]/examples/[package_module].py /[package_name]/docs/[package_module].py Then each module has its tests, docs, and examples all mixed in the one directory. This is nice if you want to have all of the tests together, and all of the docs, and examples together. However then all of the modules are mixed in together. Meaning it is harder to separate them, and keep one module in its own directory. Having everything for one thing together is nicer for developers I think. Using namespace packages through setuptools distribute is one way. There is a draft pep around to put namespace packages into python...