It's form over content. I don't see the point of it. Here's what you're gaining:
- 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.
I think he's got a point, though. Like why do I need both `setup.cfg` and `setup.py` (this one bothers me the most if `setup.cfg` contains one or two keys)? Why can't things like `.pylintrc`, `.coveragerc`, `.travis.yml`, `AUTHORS`, `CHANGELOG`, `CONTRIBUTING`, and `MANIFEST.in` go into a subfolder? I do like how e.g. flake8 just uses the `tox.ini` file for it's settings. While I can understand why `.travis.yml` makes sense to be separate, `.coveragerc` is usually like 5 lines long.
`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.
Whilst I understand the motivation behind this, introducing a new way of doing things hurts more than helps.
https://xkcd.com/927/
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 does 2 things before other commands: delete __dev__/package_name, and copy files from root to __dev__/package_name.
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".
- 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.