Description

Ignacio Vazquez-Abrams noted that if pyo files are present Django copys them into projects/apps. Currently, core.management.base stops pyc's from being copied but does not stop pyo's. Ignacio proposed adding the same block on pyo's (see patch attached).

A third possibility (If there are files other than .py that need processing) is to just add an "or f.endswith("$py.class") to the list for Jython. I'll put that patch together if it will speed things along...

Because 1.1 is released, 1.0.X will now only receive security bug fixes, so this won't be backported (unless policy changes).

That's a shame. I understand that Django is run by volunteers and you can't afford to make all the releases we want. The problem here is that Django 1.1 hasn't been tested with Jython as extensively as 1.0, so we Jython users are a bit in the dark now :(

That's a shame. I understand that Django is run by volunteers and you can't afford to make all the releases we want. The problem here is that Django 1.1 hasn't been tested with Jython as extensively as 1.0, so we Jython users are a bit in the dark now :(

Changing the policy regarding backporting would make more work for our release manager, so I'm loathe to suggest that.

Perhaps someone from the community could set up a git/hg mirror that is "1.0.X plus Jython fixes"? With mercurial at least, it is pretty easy to do - just clone ​http://bitbucket.org/mirror/django-10x/, create a 'jython_fixes' branch (or something like that) which has hand-selected backports (like changeset r11483) added to it. Provided the fixes for Jython are small, merging from django-1.0.X will be very easy.