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.
I have added several Django-related package maintainers to the CC and am very hopeful for your collaboration.
[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.]
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.
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.
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).
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.
ps Yury, see the bug report that this bug depends on; the python-django rename review is there https://bugzilla.redhat.com/show_bug.cgi?id=737293
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. Thanks!
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. Thanks!
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. Z.
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 :) Bohuslav.
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... :-(
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
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). Thanks! [1] https://fedoraproject.org/wiki/User:Bkabrda/Django_rename
Wrongly added a dependency bug 840396, should be 840369
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: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
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.
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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.