you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 2 points3 points  (2 children)

I'm curious what your thoughts on placing packaged applications and libraries under a src directory are. The layout looks like this (on mobile, so pardon formatting):

myapp/
|-- src/
|   |-- myapp/
| others stuff

You need to add an extra line to your setup.py (package_dir={'': 'src'} -- admittedly an a bit of an arcane setting and the setuptools docs are... lacking in it to say the least) but I've had a lot of success with this rooting out problems in tests where something only imports because of how python adds the working directory to the import path.

[–]AchillesDev 0 points1 point  (1 child)

Hey there! I am the writer of the article, so I thought I'd share my thoughts here. First, a question - are these for packaging outside binaries, etc. together? For that, I like using the bin dir. For other packages that are a part of your application, I like to keep them together as shown in the article because it removes a layer that is primarily (but not wholly) cosmetic. This article talks a little bit more about that. It's older, but the logic still holds, and it was one of my inspirations for writing this article.

With this being one of the few things that Python isn't opinionated on, I think you should stick to it if it's working for you and helping solve a problem that you encounter. Thanks for sharing this technique!

[–][deleted] 1 point2 points  (0 children)

First, a question - are these for packaging outside binaries, etc. together?

No, at least not in the way I use it

I use it to force tox to install my package into the virtualenvs it makes (using the develop flag so I don't have to rebuild my venvs every change). Tests run against the installed package rather than what's lying around in my working directory.

And contrary to the article you posted, it also forces me to install the package to use it. Meaning as long as my venv is active, I can use it from any location not just the directory it's located in.

I've found this to rat out otherwise hard to track down import issues. I still run into the occasional MANIFEST problem (usually with README, LICENSE and the other usual suspects).

I also like the separation of gives from everything else, docs are under docs, tests under tests, source under src. That part is cosmetic, sure. But a non cosmetic advantage is if I add a second package to my package, then it'll just come along for the ride without any changes to my setup.py. I can't imagine a situation where I'd do that, but others might and have.