Code

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#6275 closed (wontfix)

An "official" place to put applications

Reported by: marinho Owned by: nobody
Component: Contrib apps Version: master
Severity: Keywords: apps, django.contrib
Cc: robillard.etienne@… Triage Stage: Unreviewed
Has patch: no Needs documentation: yes
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Some developers use the project path to put applications in, some others put in a 'apps' folder or something like this.

Would be nice once place to import from applications from, like the following example:

from django.apps import myapp

To turn this possible, I think will be necessary exists a way to 'register' the application with a simple name (or change INSTALLED_APPS to 2-tuples-style).

Attachments (0)

Change History (9)

comment:1 Changed 7 years ago by brosner

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

This is out of scope for Django. You can accomplish this however you like with the use of PYTHONPATH and/or sys.path. Ask on django-users on some of the best practices others are doing to accomplish something similar.

comment:2 Changed 7 years ago by marinho

  • Resolution invalid deleted
  • Status changed from closed to reopened

I disagree.

I know the best practices but I wish this idea be availed better because we can gain cohesion and flexibility. An "application registration" would turn possible an applications repository, turning them more plugable than are today.

comment:3 Changed 7 years ago by erob

  • Cc robillard.etienne@… added
  • Component changed from Uncategorized to Contrib apps
  • Keywords apps, django.contrib added
  • Needs documentation set

I agree with the idea of picking a standard namespace for user-contributed django apps. Having such a scheme
documented more extensively in django could leads to things like marinho mentioned.

comment:4 Changed 7 years ago by ubernostrum

  • Resolution set to invalid
  • Status changed from reopened to closed

This is out of scope for Django; aside from certain minimum necessities like the existence of a models module inside an application, Django does not and will not attempt to dictate where you put your code.

comment:5 follow-up: Changed 7 years ago by erob

  • Resolution invalid deleted
  • Status changed from closed to reopened

Sorry but I don't agree. If we want users to distribute third-party applications on top of django, then why not explaining how
to distribute them using setuptools ?

I dont think this has nothing to do with dictature (really).
It's only being nice to users (developers) wanting to adopt a common standard for sharing contributed apps.

Person who say it cannot be done should not interrupt person doing it. --Chinese Proverb

comment:6 Changed 7 years ago by marinho

I agree to Erob and I think a common namespace or something kind of solution would be possible to developer put the applications WHEREVER wants. Today, the developer must put all of apps in once place, or create symlinks (Windows doesn't supports) or include miriads of paths to PYTHONPATH.

comment:7 Changed 7 years ago by adrian

  • Resolution set to wontfix
  • Status changed from reopened to closed

Hello there,

I don't understand what this is proposing, as it is currently written. For that reason, I'm marking this as "wontfix." If you want to provide a fuller explanation of your idea, please open a new ticket rather than reopening this one.

comment:8 in reply to: ↑ 5 Changed 7 years ago by ubernostrum

Replying to erob:

Sorry but I don't agree. If we want users to distribute third-party applications on top of django, then why not explaining how
to distribute them using setuptools ?

Isn't it the job of setuptools to document how to use setuptools?

comment:9 Changed 7 years ago by marinho

Adrian, ok (and I thank for your interest).

I wrote the following task: #6300

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.