Bug 736776 - Django package and applications are named inconsistently
Summary: Django package and applications are named inconsistently
Alias: None
Product: Fedora
Classification: Fedora
Component: Django
Version: 19
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Steve Milner
QA Contact: Fedora Extras Quality Assurance
Depends On: 737293 799650 799896 800294 803350 804185 806233 806299 806355 806516 806557 806562 806594 807256 815511 815521 816126 816323 816334 825496 825510 825511 825512 827752 830418 830421 832178 832727 835208 839301 839382 839880 839881 839882 840171 840396 840714 845458 845465 845890 848705 911543 913527
TreeView+ depends on / blocked
Reported: 2011-09-08 16:21 UTC by Yury V. Zaytsev
Modified: 2015-02-17 13:52 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-02-17 13:52:23 UTC
Type: ---

Attachments (Terms of Use)

Description Yury V. Zaytsev 2011-09-08 16:21:53 UTC
Description of problem:

At the moment, Fedora Rawhide ships Django in a package named 'Django' and the add-on applications for Django in packages that are inconsistently named.

In particular, South (the database migration library or application in Django terminology) is shipped in a package Django-south (note the capital) and the rest of the packages containing add-on libraries for Django are shipped as django-*.

To my mind, this is both inconsistent with other packages in Fedora [1] and also against established Fedora packaging policies [2].

Django is a Python web framework and as such is not a program, but rather a Python library, that in essence allows the programmer for creating web sites in Python, by importing the functionality from this library.

'Applications' in Django speak are not programs, but rather additional libraries, that build on top of Django library, implementing extra features that programmers may rely upon.

Hence, according to Fedora Package Naming Guidelines, the package name of such library should be prefixed with "python-", because it is not a stand-alone program (unlike, for instance, Trac, which is consistently named "trac").

Moreover, Flask, another web framework provided by Fedora, is consistently packaged as 'python-flask'. Flask add-ons are packaged as 'python-flask-*' e.g. 'python-flask-assets'.

Same is true for other libraries, unrelated to web development, for instance, Twisted, packaged as 'python-twisted*' etc.

[1]: http://download.fedora.redhat.com/pub/fedora/linux/development/rawhide/source/
[2]: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28python_modules.29

Expected results:

I would like to see Django renamed to 'python-django' and Django applications to 'python-django-*'.

It is important to keep the package names consistent within the distribution, to provide better user experience and all web frameworks should be named according to the same pattern.

Moreover, sooner the packages are renamed, less effort the rename will take. I've seen many review request for Django applications. It is essential to establish a consistent naming pattern before a large number of users starts relying upon the existing names.

Additional info:

I am willing to help with this migration. My suggestion is to rename all packages and add 'Obsoletes' to each of them to ease the upgrades.

Please let me know how exactly I can contribute to this effort.

Comment 1 Yury V. Zaytsev 2011-09-08 16:27:32 UTC
I have added several Django-related package maintainers to the CC and am very hopeful for your collaboration.

Comment 2 Dave Malcolm 2011-09-08 16:34:07 UTC
[Semi off-topic, but FWIW, I'd like us to eventually have Django packaged for pypy (and python3, when Django eventually supports that).

So if the great renaming happens, I think I'd eventually want "pypy-django" and "python3-django" packages, maybe built as subpackages from the main django src.rpm, maybe not.  Having the src.rpm and the regular CPython 2 package be named python-django lends itself to more consistency, so FWIW I like this idea.  Renames are a pain though.]

Comment 3 Yury V. Zaytsev 2011-09-08 16:57:34 UTC
This is a very good point; I concur.

For now Django is still poorly usable on PyPy, but the situation is quickly improving and potentially it will provide huge savings in production, so it would be wise to keep this possibility open, instead of having to come up with nasty kludges later on.

Comment 4 Dimitris Glezos 2011-09-09 14:47:02 UTC
Please note that there are also Django Projects, which are standalone. Contrary to normal Django apps, they aren't used as a library.

An example is transifex. Its name should remain like that and not django-transifex or something.

Comment 5 Yury V. Zaytsev 2011-09-09 14:51:51 UTC
Quite certainly so, transifex is a stand-alone application that uses Django as a library, so it should remain packaged as transifex, like other stand-alone web applications (i.e. trac).

Comment 6 Michel Alexandre Salim 2011-09-10 17:46:45 UTC
I'm pushing out a Django security update in the next couple of minutes, but after that, we can consider the package rename (since there's a request for a python26-django for EPEL5, it's probably a good time to effect a name change anyway).

As the initial packager of Django, mea culpa -- my rationale was that it shipped with some tools, so it's not a pure library per se, but it certainly is not meant to be used as a stand-alone program either.

Yury, would you be willing to do a review once it's ready? And unless any of the current maintainers want out, I'm guessing the ACL for the new package will be identical to the current one.

Comment 7 Michel Alexandre Salim 2011-09-12 17:38:42 UTC
ps Yury, see the bug report that this bug depends on; the python-django rename review is there


Comment 8 Yury V. Zaytsev 2011-09-12 18:33:15 UTC
Hi Michel,

Thanks for getting back to me!

(In reply to comment #6)
> As the initial packager of Django, mea culpa -- my rationale was that it
> shipped with some tools, so it's not a pure library per se, but it certainly is
> not meant to be used as a stand-alone program either.

I don't think that you or anyone else in particular is to blame for that. In fact, to my mind, the policy is not elaborate and/or strict enough in this regard, which is the root cause for the current situation.

For instance, making serious use of the exceptions theoretically allowed under the current policy, like 'if the module name starts with "py" you can use it as the package name' and 'if in doubt, use the string that you use to import the module as a package name' is just begging for trouble.

Not only it's a consistency and user experience problem, but also a technical issue. The support for multi-python2/3 setups is becoming increasingly important, but also as Dave has rightfully noted, alternative implementations such as PyPy are maturing and becoming a more and more interesting/requested target to support.

In this case having a strict convention of using 'python' / 'python3' / 'pypy' as a prefix for modules would certainly save maintainers and packagers a lot of sweat.

I think this case warrants a wider discussion among Python maintainers in Fedora and possibly some policy revisions with the experience gained in the process of adding python3, but being very new to the community I'm completely clueless on how to go about that.

So I decided to start with suggesting to consider fixing one real issue that I am experiencing right now. I am very thankful and highly appreciate your constructive feedback!

> Yury, would you be willing to do a review once it's ready? And unless any of
> the current maintainers want out, I'm guessing the ACL for the new package will
> be identical to the current one.

Sorry, I am very busy during the week days, but I will for sure have a look at your update towards the end of the week, as I need to get it packaged into our RHEL6 infra repos for $work.

I will check the diffs, mock rebuild, rpmlint & maybe test the package and report the results, but I am not sure if I can be of help beyond that. So far I have not been not involved with Fedora and I don't think I can give you any official sign-offs or anything like that.


Comment 9 Bohuslav "Slavek" Kabrda 2012-01-18 06:56:58 UTC
Hi guys.
I think that renaming the Django modules is a good idea, but perhaps you could somehow give heads up to the community? About two weeks ago, I created django-tastypie and only by coincidence I came across this - had I known, I would have already named it python-django-tastypie. Here are some suggestions:

- Write to python-devel mailing list so that all python developers know about it.
- Discuss with FPC.
- Create a special section in Python packaging guidelines, so that everyone knows from the beginning, how to name their package.


Comment 10 Yury V. Zaytsev 2012-01-18 07:10:13 UTC
Hi Bohuslav,

Thanks for the heads up!

Sorry, I didn't follow up on this bug, because I had an urgent need to get Django packaged for my RHEL5/6 infra repos and ended up re-packaging it along with the modules as python-django-*, since I needed to tweak every module to build cleanly on RHEL anyway...

I think your suggestions make a lot of sense, the problem is that as I stated, I do not actively participate in the community and know very little about the process.

I would be very happy if you could use my texts above to get this process started.


Comment 11 Bohuslav "Slavek" Kabrda 2012-01-18 07:23:39 UTC
Hi Yury,
thanks for the quick response! I'll certainly try to get the process started, first by discussing on the python-devel mailing list - maybe you could subscribe there and watch the discussion that will come out of it. We'll see what the outputs of this little brainstorming :)


Comment 12 Yury V. Zaytsev 2012-01-18 07:40:34 UTC
I'd appreciate you CC'ing me for starters, since I'm afraid I gonna be lost in the additional traffic if I subscribe straight away... :-(

Comment 13 Bohuslav "Slavek" Kabrda 2012-01-25 12:15:26 UTC
Just a quick update:
at [1] you can find the whole discussionon python-devel mailing list. I think that there is no need to contact FPC, the guidelines for renaming [2] are pretty clear, so I think that nothing stands in our way.

[1] http://lists.fedoraproject.org/pipermail/python-devel/2012-January/000335.html
[2] http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages

Comment 14 Bohuslav "Slavek" Kabrda 2012-03-07 14:27:24 UTC
Hi guys,
I created a wiki page, that summarizes the progress on this issue [1]. I'd be glad if you could read it and collaborate on getting this done (perhaps discuss on python-devel list).


[1] https://fedoraproject.org/wiki/User:Bkabrda/Django_rename

Comment 15 Yuguang Wang 2012-08-03 09:14:23 UTC
Wrongly added a dependency bug 840396, should be 840369

Comment 16 Fedora End Of Life 2013-04-03 17:39:06 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:

Comment 17 Fedora End Of Life 2015-01-09 16:46:32 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 18 Fedora End Of Life 2015-02-17 13:52:23 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.