For all the grief Kenneth Reitz gets... gotta give him credit for his emphasis on usability and professional presentation.
Why does he get grief?
Structuring Your Project
11–20 of 40 posts
Re: Structuring Your Project
#12When I'm just learning a new programming language or framework, I prefer to have something like create-react-app [0], django-admin startproject [1], cargo new [2], or lein new [3]. Guides like these are just full of (the wrong type of) rabbit holes. Just give new people something that lets them work productively as soon as possible and refer them to language documentation to understand how features of the language or…
Given Python's history, there are just too many "one way"s to do things.
The space of packaging has changed hugely in the last 5 years, and probably will again in the next 5 (both in good ways).
Maybe then we get a standard templater.
Though sure, if poetry is your thing, it does this.
(Me, FWIW, given that I still generally stick to setuptools for better or worse, I have my own templater that I use [0])
Re: Structuring Your Project
#13Always one of the good articles to link to when creating a Python repo from scratch. Should mention that __init__.py is not needed for python 3.3+ anymore (just found that out this week myself to my surprise) so for projects where backwards compatibility is not required you can stop creating extra blank files if you don't need them. https://stackoverflow.com/questions/37139786/is-init-py-not-...
Although, beware that you may need to change `find_packages()` to `find_namespace_packages()` in your setup.py.
I get burned by that one a lot!
Re: Structuring Your Project
#14For all the grief Kenneth Reitz gets... gotta give him credit for his emphasis on usability and professional presentation.
Why does he get grief?
Re: Structuring Your Project
#15This is the kind of documentation I wish every language/framework provided. Every time I try to learn a new language/framework, I just see code fragments with no idea how to organize them coherently. This month I'm working on a side project and learning to use sequelize (a SQL ORM for node). All the examples [1] just seem to assume my entire project live in a single file. [1] https://sequelize.org/master/manual/model…
The most frustrating part of learning new tech stack is the implicitly assumed tribal knowledge.
ex. s.o answers start with np.yada without the import numpy as np part.
Re: Structuring Your Project
#16When I'm just learning a new programming language or framework, I prefer to have something like create-react-app [0], django-admin startproject [1], cargo new [2], or lein new [3]. Guides like these are just full of (the wrong type of) rabbit holes. Just give new people something that lets them work productively as soon as possible and refer them to language documentation to understand how features of the language or…
`poetry new`[0] is what you are looking for, previously I have used pyscaffold[1] but I like the pyproject.toml from PEP 518[2] better than all the old stuff. Unfortunately poetry does not set up docs like pyscaffold does though. [0]: https://poetry.eustace.io/ [1]: https://pyscaffold.org/en/latest/ [2]: https://www.python.org/dev/peps/pep-0518/
poetry new --src projectname
is my preference these days.
Re: Structuring Your Project
#17Always one of the good articles to link to when creating a Python repo from scratch. Should mention that __init__.py is not needed for python 3.3+ anymore (just found that out this week myself to my surprise) so for projects where backwards compatibility is not required you can stop creating extra blank files if you don't need them. https://stackoverflow.com/questions/37139786/is-init-py-not-...
That's really not recommended. A lot of behaviors are subtly affected by failing to have init files.
Re: Structuring Your Project
#18The best answer in 2020 is to use poetry.
Re: Structuring Your Project
#19Whenever I start a new Django / Python project I come up with a short and generic(ish) internal name, like “pluto” - then, the repo is structured like this:
README.md
runtime.txt
requirements.txt
pluto
wsgi.py
manage.py
urls.py
- conf
- common.py
- prod.py
- local.py
- static
- templates
- apps
- accounts
- models.py
- etc
- users
- etc
pluto
\ src
\ pluto
I also use relative imports from within the “apps” directory:
# e.g., inside pluto/apps/accounts/views.py
from ..users.models import User
Re: Structuring Your Project
#20Always one of the good articles to link to when creating a Python repo from scratch. Should mention that __init__.py is not needed for python 3.3+ anymore (just found that out this week myself to my surprise) so for projects where backwards compatibility is not required you can stop creating extra blank files if you don't need them. https://stackoverflow.com/questions/37139786/is-init-py-not-...
That's really not recommended. A lot of behaviors are subtly affected by failing to have init files.
Like what?