Honestly, this is one of the things I really appreciate about the development workflow at $dayjob. Our Python build process is fairly custom for what amounts to historical reasons, but when you create a new Python project, you get automated builds and tests on all the OSes you care about (through our central build and test farm), a way of declaring dependencies (that has nothing to do with pipenv/poetry/etc., but whatever), flake8 enabled by default easy toggles for mypy and black if you want them, a standard way of doing code reviews, a standard way of doing releases, etc. - simply because it's possible to assume shared infrastructure and shared defaults.
When you're writing open-source code, you don't have any shared infrastructure or defaults to assume, so you have to find some infrastructure (e.g. GitHub + Travis) and you have to basically include all the infrastructure configuration in your project, possibly through adding a bunch of dev-dependencies that set things up the way you want. It'd be interesting to think about how to abstract this further so you don't have to think about that many things.
Some possible inspirations:
- https://travis.debian.net/ - if you have a Debian package on GitHub, and you want automated tests, you just grab the .travis.yml file from here and a script written by someone else will set up builds and tests in Docker containers. It does rely on Debian having a standardized way of specifying build rules, dependencies, and tests and a standardized layout of packages, though. But most Python packages have a pretty standard layout, too, and you can imagine having things like isort/flake8/nose/etc. be installed only in CI and not explicitly listed in your code.
- Rust, I think, makes this a little easier because there's a high-quality packaging system, test runner, formatter, and doc generator all in the standard Rust tools. While Rust-the-language has a standard library that's much emptier than, say, Python's, rustc comes with way more developer tools than Python does. That means that you don't need to install custom tools to handle most of this because it's assumed that people are using the standard ones. (This does, of course, rely on the tools actually being high-quality, and as a young language, Rust has an unfair advantage in watching Python and so many other languages try to figure out what works well and what doesn't. You'd have an easier time in Python if you stuck to distutils and easy_install, but on the other hand, you'd have to use distutils and easy_install.)
When you're writing open-source code, you don't have any shared infrastructure or defaults to assume, so you have to find some infrastructure (e.g. GitHub + Travis) and you have to basically include all the infrastructure configuration in your project, possibly through adding a bunch of dev-dependencies that set things up the way you want. It'd be interesting to think about how to abstract this further so you don't have to think about that many things.
Some possible inspirations:
- https://travis.debian.net/ - if you have a Debian package on GitHub, and you want automated tests, you just grab the .travis.yml file from here and a script written by someone else will set up builds and tests in Docker containers. It does rely on Debian having a standardized way of specifying build rules, dependencies, and tests and a standardized layout of packages, though. But most Python packages have a pretty standard layout, too, and you can imagine having things like isort/flake8/nose/etc. be installed only in CI and not explicitly listed in your code.
- Rust, I think, makes this a little easier because there's a high-quality packaging system, test runner, formatter, and doc generator all in the standard Rust tools. While Rust-the-language has a standard library that's much emptier than, say, Python's, rustc comes with way more developer tools than Python does. That means that you don't need to install custom tools to handle most of this because it's assumed that people are using the standard ones. (This does, of course, rely on the tools actually being high-quality, and as a young language, Rust has an unfair advantage in watching Python and so many other languages try to figure out what works well and what doesn't. You'd have an easier time in Python if you stuck to distutils and easy_install, but on the other hand, you'd have to use distutils and easy_install.)