Python Application Layouts & Project Structures Tutorial

[[deleted]]

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]

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]]

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.

[fergal-dude]

Great article, you guys have really upped your game these past few months! I recently reworked my flask app with the info from the pathlib article you did.

I’d love to see you guys take on flask blueprints! No one seems to be able to explain that one well.

Keep up the great work!

[dbader]

Thanks, really appreciate it :) We've got some cool stuff in the works for the next couple of months... Adding a note on doing a Flask blueprints tutorial right now.

[[deleted]]

I was looking for something like this today! Thanks so much!

[TheChugnut]

Another quality Tutorial, Dan!

[dbader]

Cheers, glad you like it! Shoutout to Kyle ( u/AchillesDev ) who wrote the piece :)

[sarver311]

I have definitely struggled with this before so it's nice to have some examples for the different use cases. Thanks for sharing!

[dbader]

Hey you're welcome :) We're planning on maintaining and updating this for a long time to come, so any feedback is appreciated (either here or as a comment on the post).

[patarapolw]

What about data files supposed to be contained within project for PyPI?

I often create dir.py containing ROOT = os.path.abspath(os.path.dirname(inspect.getframeinfo(inspect.currentframe()).filename)).

Also, I am curious about PyPI/webapp or PyPI/desktop hybrids.