
Show HN: Insideout – does this new approach to Python packaging makes sense? - ffunenga
https://github.com/ffunenga/insideout
======
viraptor
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.

~~~
guitarbill
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
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

------
mattdeboard
I'm not sure file/directory layout even cracks the list of top ten problems
with Python's packaging.

~~~
pjdkoch
This. Right here.

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.

------
mborch
No it doesn't.

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.

------
dec0dedab0de
sometimes I like to pip install directly from git, I don't think that would be
possible with this setul.

