2 ms·

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

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.

w_t_payne 11y ago
Whilst I understand the motivation behind this, introducing a new way of doing things hurts more than helps. https://xkcd.com/927/ 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

w_t_payne 11y ago

Whilst I understand the motivation behind this, introducing a new way of doing things hurts more than helps. https://xkcd.com/927/ 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