setup.py for Django project?

[Scot Hacker]

I am accustomed to seeing pip-installable dependencies of a Django project each have their own `setup.py`. I am not accustomed to seeing a Django project *itself* have its own `setup.py`, but I am now working with a project that does just that. The setup does not move the Django project itself to `site-packages`, but does add the whole project to the Python path.

This approach is not documented or recommended by Django itself, and I can't find many references to it on the web. The stated advantages are that it lets you use `manage.py` from any dir (not just the top-level) and that it simplifies the writing of fab commands. I am wary of it because it (slightly) complicates setup, is unusual, confusing to new developers, etc. 

Does anyone have experience with this approach? In 10 years of Django development, I've never encountered this on a project, and it feels a bit... strange to me. But would love to hear from anyone who has had positive or negative experiences doing this. 

Thanks for any feedback,

Scot

[Ben Lopatin]

I've seen this on a few projects before and each time transitioned the project away from it.

As you note, for whatever advantages it seems like there may be, it's very much atypical and also unnecessary. I don't see how it makes writing Fabric tasks significantly easier (presumably you don't need to reference the project path? which saves the uses of one variable or something) and you can use django-admin.py from anywhere without this, provided your path is updated in the environment.

Would be open to someone chiming in about a specific use case in which using setup.py to install a Django project is a significant advantage but all things being equal I'd not rely on it.

[callsa...@gmail.com]

hi,

yes, django has `setup.py`, that's `manage.py`,LOL

depend on how you think. 

if you code is like `tools`, that use `setup.py`

like your code is a `calculator`.

if not, that's many way to setup, like Fabric, Ansible,etc.

think this two word, `functional` and  `system/project`

for python, see PEP-400

====

"Projects" are software components that are made available for integration. Projects include Python libraries, frameworks, scripts, plugins, applications, collections of data or other resources, and various combinations thereof. Public Python projects are typically registered on the Python Package Index.

====

["Александр Христюхин (roboslone)"]

`manage.py` is ABSOLUTELY NOT a `setup.py`. It doesn't really matter how you think.

`setup.py` is used for package managing while `manage.py` manages Django.

-- 
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/940b4795-dfd5-44c6-8766-72f2e2471a35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Scot Hacker]

Thanks for the feedback everyone. Good to get some real-world input on non-standard approaches like this. I'm going to try and steer the project away from it.

And I agree that manage.py and setup.py are not interchangeable at all - especially since not everything *goes* through manage.py.

./s