Show HN: Insideout – does this new approach to Python packaging makes sense?
github.com
github.com
- layout which some people prefer
What you sacrifice:
- standard layout expected by pretty much all the tools
- `setup.py develop` (setup installs a copy of the files)
- proper change notification (so webapp development can't auto-refresh anymore)
- standard configuration files which services depend on (travis, gitignore, license, contributing, appveyor, coverage)
- (haven't checked, so "likely") pbr compatibility
Also, this takes a completely dev/code-centric approach - the app is "code and some ugliness". But actually the app is the code, the tests, configuration, packaging, documentation, service integration, and a few others. All are important.
`pbr` seems like a step in the right direction. But right now, it feels a lot like Linux/BSD/Unix, where every dot file used to go into `~/`. Happily, we've started putting stuff into `~/.config/$APPNAME`, which reduces the clutter and makes backups/restoring much easier (Which you can also do with git! Something I only found out recently) So a `.config` directory in a repo would be neat.
In particular, I think that the setup.py needs to stay right in the repo root. It's an affordance thing. It is probably the single most common way of interacting with any given package, so it should advertise itself prominently and sit right where people can most easily see it.
Similarly, I don't think that having the module scripts in the root of the repository is at all helpful for those who just want to use (and not actually contribute to) the library.
I guess it is a question of balancing the needs of different sorts of consumers. However, given that (under most circumstances) count(users) >> count(contributors), prioritising the needs of users over contributors is entirely justifiable.
One point where we agree is on the ugliness of configuration files in the repo root. After all, the following is true: count(users) >> count(contributors) >> count(package-mantainers). As a result, I would be quite happy to support a convention that places package configuration (and other tool configuration) files in a .config subdir: <reporoot>/.config/.<toolname>rc
> `setup.py develop`
`python __dev__/setup.py develop` works correctly
> (...) But actually the app is the code, the tests, (...) All are important.
`insideout` doesn't delete the ugliness. It merely postpones it from the viewer's eyes
That means if you do `setup.py develop`, your links are pointing to the copy inside of __dev__, and not to the files in the root directory. So even if you modify files and commit changes, the installed link still points at the old installation - which is exactly how `develop` is not supposed to act.
> `insideout` doesn't delete the ugliness. It merely postpones it from the viewer's eyes
I'd say it prioritises what's supposed to be "important". And it's a very one-sided view of "important".
All these small necessary evils are nothing compared to bigger pains. From the top of my head.
I'd kill to have a Gemfile scheme that's actually used by everybody. We could emulate this pretty darn closely with setup.py and requirements.txt (for Gemfile and Gemfile.lock, respectively). But, most of us just don't. Tox generally makes matters worse (since it promotes people dropping even more untracked deps in there), even though it's a great tools for what it was designed.
I think most people would be surprised to find the package's contained module in the root of the repository because it's not one-to-one with what will end up being "installed".
Also, a package can install multiple modules.