Update on localflavor move

[Adrian Holovaty]

Hi all,

We've been talking about moving django.contrib.localflavor into
separate packages, outside of Django proper
(https://groups.google.com/d/topic/django-developers/OiyEGmXTifs/discussion).
Today I did the work of creating the django-localflavor-* packages and
copying code/tests/docs to them.

Now we have 44 django-localflavor-* projects on our Django GitHub
account, and you can see them here:

https://github.com/django

From now on, please consider django.contrib.localflavor to be READ-ONLY:

* If you have any existing pull requests for localflavor, please close
them and open them again on the appropriate django-localflavor-*
project.

* If you have any existing Trac tickets for localflavor, please close
them and open a pull request on the appropriate django-localflavor-*
project.

* If you're a committer, please don't make changes to
django.contrib.localflavor. You have commit rights on all
django-localflavor-* projects, so commit changes there.

Eventually we'll be removing django.contrib.localflavor, in favor of
these outside packages. I've updated the localflavor docs to note the
new code location and tips on migration:

https://docs.djangoproject.com/en/dev/ref/contrib/localflavor/

Here are the outstanding to-dos with this effort:

* Move/copy translations into the django-localflavor-* packages. This
is outside of my expertise, so does anybody want to take the lead on
this?

* Document a clear way to run the tests for a given
django-localflavor-* package. I moved the tests into the separate
packages, but there's no clear way to run them. Any suggestions?

* Add DeprecationWarning to django.contrib.localflavor in trunk,
before Django 1.5. I will take care of this.

* I'll write up a more formal message for django-users and the
djangoproject.com blog.

Adrian

[Russell Keith-Magee]

On Sat, Oct 13, 2012 at 6:21 AM, Adrian Holovaty <adr...@holovaty.com> wrote:
> Hi all,
>
> We've been talking about moving django.contrib.localflavor into
> separate packages, outside of Django proper
> (https://groups.google.com/d/topic/django-developers/OiyEGmXTifs/discussion).
> Today I did the work of creating the django-localflavor-* packages and
> copying code/tests/docs to them.
>
> Now we have 44 django-localflavor-* projects on our Django GitHub
> account, and you can see them here:
>
> https://github.com/django

w00t! Nice work, Adrian!

> Here are the outstanding to-dos with this effort:
>

> * Document a clear way to run the tests for a given
> django-localflavor-* package. I moved the tests into the separate
> packages, but there's no clear way to run them. Any suggestions?

The best option I've see for this sort of thing is tox:

http://tox.testrun.org/

This allows you to specify the PyPI packages (and versions) that need
to be installed in order to run the test suite, and automates the
process of setting up the test environment (using virtualenv). If code
needs to run as part of a larger project, tox can coordinate running
the tests in that project. It also integrates nicely with CI servers,
and it allows for easy testing across Python and Django versions.

To pick an example at random: here's the tox.ini file for
Easy-thumbnails, which tests Py2.5-Py2.7, Django 1.2-1.4, as well as
the documentation build.

https://github.com/SmileyChris/easy-thumbnails/blob/master/tox.ini

Russ %-)

[Claude Paroz]

Le samedi 13 octobre 2012 00:21:16 UTC+2, Adrian Holovaty a écrit :

Hi all,

We've been talking about moving django.contrib.localflavor into
separate packages, outside of Django proper
(https://groups.google.com/d/topic/django-developers/OiyEGmXTifs/discussion).
Today I did the work of creating the django-localflavor-* packages and
copying code/tests/docs to them.

Now we have 44 django-localflavor-* projects on our Django GitHub
account, and you can see them here:

Thanks Adrian for your work.
(...)

* If you have any existing Trac tickets for localflavor, please close
them and open a pull request on the appropriate django-localflavor-*
project.

You meant: open an issue?
 

Here are the outstanding to-dos with this effort:

* Move/copy translations into the django-localflavor-* packages. This
is outside of my expertise, so does anybody want to take the lead on
this?

I can work on this, however I'm wondering if it makes sense to re-add all translations in all packages. Is adding Korean translation to Switzerland localflavor useful?
 

  * Add DeprecationWarning to django.contrib.localflavor in trunk,
before Django 1.5. I will take care of this.

Did we decide on an accelerated deprecation here, or did you mean PendingDeprecationWarning?

Claude

[Tomas Ehrlich]

Salut Claude,

> I can work on this, however I'm wondering if it makes sense to re-add all
> translations in all packages. Is adding Korean translation to Switzerland
> localflavor useful?

I think it is. If someone translated Switzerland localflavor into
Korean language it means that he might need it (for whatever reason).


Anyway, thanks Adrian for this work. It's awesome.

Dne Sat, 13 Oct 2012 00:57:56 -0700 (PDT)
Claude Paroz <cla...@2xlibre.net> napsal(a):

S pozdravem
Tomáš Ehrlich

Email: tomas....@gmail.com
Tel: +420 608 219 889
Jabber: elv...@jabber.cz

"Půjdu kamkoliv, pokud je to kupředu." - J. London

[Shai Berger]

On Saturday 13 October 2012, Tomas Ehrlich wrote:
> Salut Claude,
>
> > I can work on this, however I'm wondering if it makes sense to re-add all
> > translations in all packages. Is adding Korean translation to Switzerland
> > localflavor useful?
>
> I think it is. If someone translated Switzerland localflavor into
> Korean language it means that he might need it (for whatever reason).
>

As long as the localflavor was in one .po file with the rest of Django, the
reason may well have been "to keep the translation percentages in my language
up".

I suggest to keep the original Django .po's available and easily accessible
for the localflavor packages. in case someone really needs these translations,
but I don't think it makes sense to require all the porting work upfront.

(Spoken as one who once took part in one of the translations)

Shai.

[ptone]

On Friday, October 12, 2012 3:21:16 PM UTC-7, Adrian Holovaty wrote:

 

* If you have any existing Trac tickets for localflavor, please close
them and open a pull request on the appropriate django-localflavor-*
project.

Correct me if I'm wrong in interpreting this - Trac won't be used for localflavor and we should delete that component.

contributions to localflavor repos will go direct to pull requests - most of them no warranting "issues/tickets"

I'll volunteer to update our contributing docs on these points including our CONTRIBUTING root level doc - which is highlighted by github when pull requests are opened. 

-Preston

[Aymeric Augustin]

Hi Adrian,

Thanks for taking the lead on this! I reviewed related tickets in Trac and I have a few suggestions.


1) Can we move the fields defined in django.contrib.localflavor.generic.forms to django.forms?

Currently the US-biased fields are in django.forms and the non-biased ones in django.contrib.localflavor.generic.forms — an interesting perspective :)

The alternative is to deprecate them entirely.


2) There's a dozen Trac tickets for adding new countries: Bulgaria, Nicaragua, Hungary, Malaysia, Venezuela, South Korea, Bangladesh, New Zealand, Guatemala, Latvia, Iran, Singapore.

Would it make sense to create these local flavors now — maybe after asking the community to update the patches if they aren't ready?


3) I'd like to see some guidelines on what features a local flavor is expected to provide.

Two examples:
- Are model fields that just inherit TextField and set a particular form_class useful? (#10087)
- Are pluralization template filters a good idea? (#17632)

I believe it's a good thing for the Django community to maintaining some consistency among local flavors. Since we plan to defer to local maintainers in each country, we should document the expectations and best practices.


--
Aymeric.

[Mahdi Yusuf]

Hi, 

I have setup testing in a pull request here. 

If this solution is acceptable. I can duplicate the process on the other local flavours.

I would appreciate feedback. 

--

Mahdi Yusuf 

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

--

Mahdi Yusuf

[David Winterbottom]

Here's another pull request for setting up testing, this time using tox as per Russell's suggestion.

https://github.com/django/django-localflavor-gb/pull/2

AFAIK, tox requires the tests to be part of the package.  Hence I moved tests.py into the django_localflavor_gb package as well as a test settings module.  Using Django's testrunner also requires that the package has a models.py so it is considered an app.  Is is possible to use tox and the django testrunner so that the test can be separate, and the package doesn't require a models.py?  That would be cleaner in my eyes.

Feedback welcome of course.  Hopefully this is a step in the right direction for agreeing on a testing set-up for all the localflavors.

David Winterbottom
Head of Programming

Tangent Labs
84-86 Great Portland Street
London W1W 7NR
England, UK

[Łukasz Rekucki]

On 16 October 2012 11:21, David Winterbottom

<david.win...@tangentlabs.co.uk> wrote:
> Here's another pull request for setting up testing, this time using tox as
> per Russell's suggestion.
> https://github.com/django/django-localflavor-gb/pull/2
>
> AFAIK, tox requires the tests to be part of the package. Hence I moved
> tests.py into the django_localflavor_gb package as well as a test settings
> module. Using Django's testrunner also requires that the package has a
> models.py so it is considered an app. Is is possible to use tox and the
> django testrunner so that the test can be separate, and the package doesn't
> require a models.py? That would be cleaner in my eyes.
>
> Feedback welcome of course. Hopefully this is a step in the right direction
> for agreeing on a testing set-up for all the localflavors.
>
> On 16 October 2012 04:55, Mahdi Yusuf <yusuf...@gmail.com> wrote:
>>
>> Hi,
>>
>> I have setup testing in a pull request here.
>>
>> If this solution is acceptable. I can duplicate the process on the other
>> local flavours.
>>
>> I would appreciate feedback.
>>
>> --
>> Mahdi Yusuf

If we include some form of a test runner in every localflvour, I
suspect they will get out of sync quite quickly. Also, I don't think
there is a good reason for duplicating code.

Maybe we need something like django-localflavour-commons, which would
include the test harness, packaging logic (then in setup.py you can
just import it from there), etc. My first idea was to make it a
submodule, but that would still require making a commit to all repos
whenever we update the commons (althought, still simpler then applying
the same patch everywhere). We could instead put it on PyPI and make
all other packages always require it's latetest version.

--
Łukasz Rekucki

[Andre Terra]

This seems like the most reasonable approach. FWIW, why not name it just django-localflavor?

Cheers,

AT

[Carl Meyer]

On 10/16/2012 04:00 AM, Łukasz Rekucki wrote:
> If we include some form of a test runner in every localflvour, I
> suspect they will get out of sync quite quickly. Also, I don't think
> there is a good reason for duplicating code.

David's pull request seems pretty minimal to me - just a three-line
settings.py and a tox.ini. It would be nice to have some more-automatic
way to keep the tox.ini up to date.

> Maybe we need something like django-localflavour-commons, which would
> include the test harness, packaging logic (then in setup.py you can
> just import it from there), etc. My first idea was to make it a
> submodule, but that would still require making a commit to all repos
> whenever we update the commons (althought, still simpler then applying
> the same patch everywhere). We could instead put it on PyPI and make
> all other packages always require it's latetest version.

Be really careful with importing things in setup.py. A runtime
dependency is different from a can't-even-execute-setup.py-without-it
dependency; the latter means pip wouldn't even be able to install a
localflavor package unless you install the -commons package first (in a
separate step). (Setuptools has setup_requires to get around that, but
it's wonky with pip, as it won't respect any of pip's
index/mirror/find-links settings, and always goes to the main PyPI). I
don't think there's nearly enough common "packaging logic" in the
localflavors to justify any of this hassle.

A localflavor-dev package that includes requirements for running tests
on all localflavors (and has a dependency on tox, so the instructions
are still as simple as "pip install one thing and run one command")
might be ok, though the main duplication you'd want to save is in
tox.ini, and you'd need to write some extra code to help tox "inherit"
config files before you'd be able to save any redundancy there anyway.

Carl

[Tai Lee]

Hi Aymeric & Adrian,

I didn't see any further discussion or consensus on the issue of the generic localflavor. The 1.5 docs and (accelerated) deprecation of localflavor are a little hazy regarding the generic localflavor.

The 1.5 docs say that it hasn't been removed (yet), but doesn't say it will remain where it is, or move into core, or simply disappear with no equivalent external package.

The docs also said that (all of) `django.contrib.localflavor` would be removed, and any import below `django.contrib.localflavor` currently raises a warning with a message to use `django-localflavor-*` packages instead. But for generic, there is none.

So as it stands, anyone who uses `django.contrib.localflavor.generic` (all my projects do) will find that it has been removed in 1.6 with no equivalent in core and no equivalent external package.

I would prefer to see these reinstated in django core for 1.6, and the 1.5.x docs updated with an explanation on where they can be imported from when upgrading to 1.6.

It's probably a bit much to ask for the non-biased international format fields to become the defaults, but I would definitely like to see these move into core before `django.contrib.localflavor` goes away.

It would seem a bit silly to me to create an external `django-localflavor-generic` package with 3 international (not locale specific) format fields and no other localisation. Django has always had great international support in core, and I doubt these three fields are much of a burden to maintain.

Also, as a separate issue I noticed that only a handful of the `django-localflavor-*` packages are on PyPI. This makes the method inconsistent and potentially more difficult (depending on your locale) to add them as requirements to a project.

Cheers.

Tai.