I have a reverse question. Python-feedgenerator is a project that decouples "feedgenerator" from DJango and provides it as a standalone project. Any objections if I package it for Fedora?
http://pypi.python.org/pypi/feedgenerator
Very interesting... that does seem to run into the same questions as normal bundling requests (https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions ). Some questions are pretty much the same: is this a fork that will diverge over time or is the upstream for feedgenerator just taking whatever is in the current Django tree? Is the code going to be kept up to date with the parent project?
Some of the usual questions about bundling don't apply -- for instance, by decoupling, this upstream is making the code more available to third parties wanting to consume it too (leading to more possibility to share bug fixes with each other).
I think we should treat it as a standalone project, regardless of its shared history with DJango's component. It's basically just shared code that now has a life of its own, though the interesting twist then becomes -- if this is accepted for packaging, should we consider that DJango is now bundling libraries? :)
for me, this looks like a fork of a small part of Django. I'd see more sense to re-use that Django code instead of just copying that.
Well, the point of creating a standalone fork of it is to avoid pulling in Django and all its dependencies if all you want is create feeds. Specifically, this is used by Pelican -- a static site rendering software that doesn't use any other of Django's features.
I wouldn't want to see DJango required to "unbundle" feedgenerator if this gets in since django is at least equally the canonical upstream.
I agree that requiring Django is kinda defeating the purpose here... but that would be the alternative if we don't agree to an exception for this.
Any answers to these questions:
feedgenerator had never been, nor neither will be a fork of the django project. It's a packaged version of it allowing to not pull all django in order to generate feeds.
The goal is to stay compatible with django upstream, yes.
Toshio, the above is from the "horse's mouth." :)
Is that enough to have python-feedgenerator granted an exception for packaging?
I guess what isn't clear to me is why the django package can't generate a python-feedgenerator subpackage that the rest of django can pull in as a dependency, but is independently installable. Are there code changes here?
I would guess that upstream django wouldn't do that (django tends to view itself in a monolithic light. They provide everything needed for the apps written to their web framework to run.) We could do that as a downstream using python namespaces (so that a package could import django.utils.feedgenerator with only a python-django-feedgenerator package installed and not the rest of django). But that has some issues:
I've opened this ticket for a general rule which I think would address this issue as well: https://fedorahosted.org/fpc/ticket/265 but it's not yet ready to be voted on. If someone would like to turn those thoughts into a draft to move this forward, that would be fine. Otherwise, I'll be back from pycon in two weeks and will work on it then.
There's a very interesting issue here, but unfortunately it just didn't get driven forward.
I'm going to bump this back to the meeting agenda to see if there's any interest in the current committee.
We discussed this at today's meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-03-12/fpc.2015-03-12-17.00.txt):
Metadata Update from @toshio: - Issue assigned to tibbs
Login to comment on this ticket.