Re: [paver] Python 3

[Almad]

Hi,

2012/9/9 rkruppe <robin....@gmail.com>:
> Hi,
>
> I recently stumbled upon Paver, and I must say I quite impressed.
> It looks awesome and I'd really like to start using it for a project of mine
> with an already nontrivial build process, with more complexity to come
> (think game development).

Glad you are interested.

> "Unfortunately", I am in the position to use Python 3 and gladly do so, and
> while nothing dictates build scripts and core application must use the same
> language version, it would make many things easier.
> So, as suggested in issue #75, I'd be willing to work on this.

Cool!

> But I could
> use a bit of input first.
>
> 1. Which dependencies are ready, and which ones need work?
> path.py has a version with Python 3 classifier, cog likewise.
> However, both only gained that in some version later than the one included
> with paver.
> I'd prefer to not re-do their porting work but rather update the included
> version; however https://groups.google.com/forum/#!topic/paver/1O4x5U68kOk
> seems to indicate that this is problematic.
> Any suggestions on how to handle this?

I do think that python3 support is good enough argument to break some
things and leap forward.

Thus, I think we can unbundle path.py and cog and just define them as
dependencies (for those who need it, they can/should be added into
minilib).

> Is there any other Python code (that's actually imported rather than invoked
> via shell)?

I am not aware of any, there is some WIP on bundled fabric/django
support, but that could be ignored for this purpose.

> 2. Any preferences on the migration strategy?
> Dropping Python 2 seems out of question.
> On-install 2to3 (via distribute) +
> forward compatability patches seem recommended in general. Are there any
> potential (paver-specific) problems with this approach?

I have unfortunately no experiences with py3 migration, so I cannot
help you in this area.

I think only problem could be if there are internal changes in
setuptools/distribute. In some areas, there is some introspection that
might break in py3 versions.

> 2a. what's the minimum supported version? 2.5 or 2.4? Any plans to drop 2.5?
> tox only bothers with 2.5, but 2.4 fixes appear in the changelog until a few
> versions ago and I did not find anything official.
> This matters because forward compatability is easier with some 3.x features
> also introduced in 2.5+.

I don't think there is some official support, so I'd declare 2.5+
(AFAIK, 2.5 is going even to stable RHEL, my personal definition of
"ancient").

However, dropping 2.5 might be problematic as there are some jython
users and 2.6+ jython is not stable.


> 3. I gather the preferred way to contribute is forking on github and sending
> pull requests.
> Should I also create a branch in my fork, or just commit to master? Anything
> else in the way of workflow recommendations?
> (I'm a git noob, but I know mercurial.)

Yes, that is the awesome way.

It is not so important ("branch" is basically acting as separate
"repo" in git), but I think that branch is better way to do it (it is
more obvious).

> Cheers

Thanks!

Almad

[Robin Kruppe]

Okay, it's going well so far. All code as far as exercised by the unit
tests parses and runs as Python 3, and the tests pass.
I removed the included path.py and cog and mock, and replaced them
with the PyPI packages.
This kills the dry run support if I understand correctly, but I'll
find a way to restore that (perhaps monkey patch something, or submit
a patch upstream).
As for cog, I found a way to call the out() function which is also
available to the code embedded in the cog code, rather than using the
CogGenerator's method (and hacking cog to expose that). I have a
feeling this isn't always equivalent to the previous approach, but it
passes the tests.

One issue remains:
The version of Cog which supports Python 3 does not support Python 2.5
any more (for good reasons, it uses e.g. the with statement
liberally).
I see two ways to resolve this: Depend on a different version of cog
depending on the Python version, or disable the cog integration in
Python 2.5.
I'm not confident that the first can be implemented reliably (and may
lead to subtle bugs), but the second may be unacceptable.
Which way should I pursue in your opinion?

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

[Almad]

2012/9/17 Robin Kruppe <robin....@gmail.com>:

> Okay, it's going well so far.

Cool!

> As for cog, I found a way to call the out() function which is also
> available to the code embedded in the cog code, rather than using the
> CogGenerator's method (and hacking cog to expose that). I have a
> feeling this isn't always equivalent to the previous approach, but it
> passes the tests.

I have no idea how many people use that. However, I think it is
reasonable, I just didn't want to do that in minor release.

> One issue remains:
(...)

> Which way should I pursue in your opinion?

I am in favor of dropping py2.5, however I have sent the call for
rescue to the mailing list -- I'd wait a week for the responses (and
then proceed).

Thanks for your work!

Almad