subject:"\[gentoo\-dev\] \[RFC\] Initial python\-r1.eclass distutils\-r1.eclass"

On Thu, 25 Oct 2012 18:41:47 +0200
hasufell hasuf...@gentoo.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 1. there is still no way to convert shebangs via python-r1

What conversion do you expect? The docs say it clearly that the eclass
will be extended on request, so please file a clear request what you
want with an example use case.

 2. there are no equivalent functions to the python_get_* stuff which
 are sometimes necessary for broken build systems or test phases

There is python_export(). I will be happy to extend it / add
python_get*() wrappers when someone makes a clear list of what
is needed.

Example use cases will be appreciated again. Good examples will make it
possible to choose good variable names.

 3. there is no equivalent for python_mod_optimize. Having that in
 distutils-r1 does not suffice for non-distutils packages where I might
 have to do that stuff manually.

There is a lot of stuff missing for packages which try to install
Python stuff by hand rather than using proper setup. I will be happy to
provide more when I know what is actually needed and how it will be
used.

 5. distutils-r1_rename_scripts does not allow to specify a location
 possibly breaking non-standard locations (e.g. games location)

It's a quick function. Adding additional paths or changing
the algorithm won't be hard. Just don't expect me to do random stuff
just because someone may want that someday.

FYI: I've added that mindless games/bin to the paths.

 6. How can I make the python dependencies optional, e.g. that
 python:3.2 is only pulled in when gtk useflag for this package is set?

inherit python-r1

RDEPEND='gtk? ( ${PYTHON_DEPS} )'

 7. are we sure now that it's safe to ship the .pyc/.pyo files inside
 the package without side-effects?

There are side effects and they are well known. Still, none of them is
an issue important enough to outweigh the benefit.

 8. how would I manually generate implementation-suffixed scripts
 without distutils-r1?

You would use the function I would introduce when I got the request
filed and potential discussion done. Most importantly, whether there
should be a way to call 2to3 on the scripts.

By the way, did you just request two partial features instead
of requesting a way to manually install Python scripts?

 example: x11-misc/redshift-1.7-r1

Thanks. I will take a look at that package and see what is necessary to
make it buildable with python-r1.

By the way, do I understand correctly that right now you are building
stuff for a random Python implementation and removing it afterwards?
I believe that's something really worth fixing.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-10-25 Thread hasufell

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/25/2012 07:43 PM, Michał Górny wrote:
 On Thu, 25 Oct 2012 18:41:47 +0200 hasufell hasuf...@gentoo.org
 wrote:
 
 1. there is still no way to convert shebangs via python-r1
 
 What conversion do you expect? The docs say it clearly that the
 eclass will be extended on request, so please file a clear request
 what you want with an example use case.

request: A function that converts the shebang to a version specific
python shebang chosen by me.

usecase: python scripts installed by a non-distutils build system
which need appropriate shebang conversion (Unless we can fix that in a
different way.)

 
 2. there are no equivalent functions to the python_get_* stuff
 which are sometimes necessary for broken build systems or test
 phases
 
 There is python_export(). I will be happy to extend it / add 
 python_get*() wrappers when someone makes a clear list of what is
 needed.
 
 Example use cases will be appreciated again. Good examples will
 make it possible to choose good variable names.

example:
x11-misc/redshift-1.7-r1

I'll give more examples as I come across those again. This is much
afair.

 
 3. there is no equivalent for python_mod_optimize. Having that
 in distutils-r1 does not suffice for non-distutils packages where
 I might have to do that stuff manually.
 
 There is a lot of stuff missing for packages which try to install 
 Python stuff by hand rather than using proper setup. I will be
 happy to provide more when I know what is actually needed and how
 it will be used.
 

example:
x11-misc/redshift-1.7-r1

Again, I'll give more examples as I come across those.

 5. distutils-r1_rename_scripts does not allow to specify a
 location possibly breaking non-standard locations (e.g. games
 location)
 
 It's a quick function. Adding additional paths or changing the
 algorithm won't be hard. Just don't expect me to do random stuff 
 just because someone may want that someday.
 
 FYI: I've added that mindless games/bin to the paths.

that games/bin change is not sufficient since the games variables can
be modified by the user and this is supported by the games eclass. So
you have to pass an option to the ebuild developer.


 
 8. how would I manually generate implementation-suffixed scripts 
 without distutils-r1?
 
 You would use the function I would introduce when I got the
 request filed and potential discussion done. Most importantly,
 whether there should be a way to call 2to3 on the scripts.
 
 By the way, did you just request two partial features instead of
 requesting a way to manually install Python scripts?
 
 example: x11-misc/redshift-1.7-r1
 
 Thanks. I will take a look at that package and see what is
 necessary to make it buildable with python-r1.
 
 By the way, do I understand correctly that right now you are
 building stuff for a random Python implementation and removing it
 afterwards? I believe that's something really worth fixing.
 

That way was chosen to avoid an extensive patch I have already
written. The maintainer of the package did not want to keep that
around through version bumps which is understandable.

- -

Currently you seem to have focused more on distutils when writing
python-r1 which makes this eclass a bit raw.
Waiting for other developers to file feature requests instead of
figuring out those yourself before they even consider porting their
ebuild to your new eclasses seems like a questionable policy to me.
They might not be too excited about it to start discussions and
feature requests just to switch from an already working implementation.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQiYspAAoJEFpvPKfnPDWzP/UH/i3GYZjrN1J+p5XjLmB7a20F
zYpZzjRSKJqv5V2xB3obngTEHT+qvSaQ4xMUdhrwuF/XpyEjD18z93kmzq1gPvan
ofnek3WiTHxaB0AJ3RoOdYB8gPRXFZpWxtySDOFgrP322mY+sBNyHMLVQ4CIJwq5
UsRwSlJNM4yddKSmnTxdRt8unmNm9mhYcmWGtebJ7MDU1720RR/RP4TxtumvdP3y
i4EDM61+kdoyKiXIfCIkKknj4CztiPZlyrRiGTFZ63+99mbJJt0qYCPYYzf9l+MV
nCrM+zUjqGvmvMeLhMulpxbn2SW7E8PpJobwTiTR8I99voTCcHH3M9NFUhfWrbs=
=//Y7
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-10-25 Thread hasufell

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/25/2012 06:41 PM, hasufell wrote:
 1. there is still no way to convert shebangs via python-r1 2. there
 are no equivalent functions to the python_get_* stuff which are
 sometimes necessary for broken build systems or test phases 3.
 there is no equivalent for python_mod_optimize. Having that in 
 distutils-r1 does not suffice for non-distutils packages where I
 might have to do that stuff manually. 5.
 distutils-r1_rename_scripts does not allow to specify a location 
 possibly breaking non-standard locations (e.g. games location) 6.
 How can I make the python dependencies optional, e.g. that 
 python:3.2 is only pulled in when gtk useflag for this package is
 set? 7. are we sure now that it's safe to ship the .pyc/.pyo files
 inside the package without side-effects? 8. how would I manually
 generate implementation-suffixed scripts without distutils-r1? 
 example: x11-misc/redshift-1.7-r1
 

4. no equivalent to python_set_active_version

feature request: let the ebuild developer choose a python
implementation for the whole emerge process.

usecase: packages not using distutils and not supporting multiple
python abis, but detecting installed python in some way and working
with all python:2.* slots.

examples that come to my mind right now:
games-strategy/freeorion
games-action/openclonk
net-im/pidgin
app-office/libreoffice

python_foreach_impl cannot fit that
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQiZDJAAoJEFpvPKfnPDWzwaIIAKAIlQlrtxWL3gPbUZqR/XKA
H/tov9nk+yb9VoqB8Hn4k0gZ1ZicGNgPIqY777/eJ2G/F9IdT8866Lztq4lWyno8
r9LZMsesNnXxZDnDLgbIyt1DXm9ddmiC3bTi3iCpgQ54sats+icgcsZ40ya/9+k5
ouZCxnxBI7LhgWPKmtloZC2Rundcgoxk7K5le37O6P6nhH5HPI8vdXtnUmNDJ/oY
ryb6VD1hkSnkY/pcIQ7MVUspGqw45LN/INhQAMvakla4y1r9pa12rsKgMAKnoYv6
LjhWtXLJEeYx+crJvLoHjdrXBX6TS8JhBc3BOVgtU1LzccDqEkqPOoLBLHUx7Tw=
=D5Ee
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

On Thu, 25 Oct 2012 20:55:37 +0200
hasufell hasuf...@gentoo.org wrote:

 Currently you seem to have focused more on distutils when writing
 python-r1 which makes this eclass a bit raw.
 Waiting for other developers to file feature requests instead of
 figuring out those yourself before they even consider porting their
 ebuild to your new eclasses seems like a questionable policy to me.
 They might not be too excited about it to start discussions and
 feature requests just to switch from an already working implementation.

As you may have failed to notice, most of Python packages actually are
using distutils. Thus, the core goal for distutils-r1/python-r1 was to
correctly support those packages.

Now that distutils is supported well, I can start thinking about
supporting random hackish build systems. I will review redshift and
give you my thoughts.

Just note that your attitude is not motivating at all. I haven't killed
any of your kitten or forced anyone to use python-r1. Most of you
didn't even care to give a single word of feedback throughout
the development process, so your position of 'this eclass doesn't give
me shiny functions I want' is at least impolite.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

On Thu, 25 Oct 2012 20:55:37 +0200
hasufell hasuf...@gentoo.org wrote:

 On 10/25/2012 07:43 PM, Michał Górny wrote:
  On Thu, 25 Oct 2012 18:41:47 +0200 hasufell hasuf...@gentoo.org
  wrote:
  
  1. there is still no way to convert shebangs via python-r1
  
  What conversion do you expect? The docs say it clearly that the
  eclass will be extended on request, so please file a clear request
  what you want with an example use case.
 
 request: A function that converts the shebang to a version specific
 python shebang chosen by me.
 
 usecase: python scripts installed by a non-distutils build system
 which need appropriate shebang conversion (Unless we can fix that in a
 different way.)

That's a fair request. Last thing which I have to think about is
whether we want this in python-r1, or a more general shebang replacement
function in eutils.

  2. there are no equivalent functions to the python_get_* stuff
  which are sometimes necessary for broken build systems or test
  phases
  
  There is python_export(). I will be happy to extend it / add 
  python_get*() wrappers when someone makes a clear list of what is
  needed.
  
  Example use cases will be appreciated again. Good examples will
  make it possible to choose good variable names.
 
 example:
 x11-misc/redshift-1.7-r1
 
 I'll give more examples as I come across those again. This is much
 afair.

Sorry, didn't notice the sitedir use.

  3. there is no equivalent for python_mod_optimize. Having that
  in distutils-r1 does not suffice for non-distutils packages where
  I might have to do that stuff manually.
  
  There is a lot of stuff missing for packages which try to install 
  Python stuff by hand rather than using proper setup. I will be
  happy to provide more when I know what is actually needed and how
  it will be used.
  
 
 example:
 x11-misc/redshift-1.7-r1
 
 Again, I'll give more examples as I come across those.

Err, do you expect the eclass to provide a function to restore
the py-compile script you're removing?

  5. distutils-r1_rename_scripts does not allow to specify a
  location possibly breaking non-standard locations (e.g. games
  location)
  
  It's a quick function. Adding additional paths or changing the
  algorithm won't be hard. Just don't expect me to do random stuff 
  just because someone may want that someday.
  
  FYI: I've added that mindless games/bin to the paths.
 
 that games/bin change is not sufficient since the games variables can
 be modified by the user and this is supported by the games eclass. So
 you have to pass an option to the ebuild developer.

User can do many stupid things, and some eclasses are just stupid
and should be killed with fire. A lot of fire. Passing an option is
just inventing a minigun to shot a mosquito.

I will be happy to fix that whenever someone stumbles around that.
If ever. If ever distutils setup.py will actually install anything
to /usr/randomlocation/bin which will be actually supposed to be
rewritten.

  8. how would I manually generate implementation-suffixed scripts 
  without distutils-r1?
  
  You would use the function I would introduce when I got the
  request filed and potential discussion done. Most importantly,
  whether there should be a way to call 2to3 on the scripts.
  
  By the way, did you just request two partial features instead of
  requesting a way to manually install Python scripts?

Ok, looking at redshift, I'm not really sure if we really need or even
want to install implementation-suffixed scripts there. That's something
to discuss.

The main reason for implementation-suffixing of scripts is that
distutils can mangle the scripts for various implementations (i.e. 2to3
them). The side reason is ability to force a particular implementation
when no other suitable way is available (which is pretty rare).

To be honest, redshift doesn't fit either. I doubt anyone will really
need to put 'gtk-redshift-python2.6' anywhere, and both scripts will be
identical. So it may be just enough or even better just to mangle
the script to have 'python2' shebang.

  example: x11-misc/redshift-1.7-r1
  
  Thanks. I will take a look at that package and see what is
  necessary to make it buildable with python-r1.
  
  By the way, do I understand correctly that right now you are
  building stuff for a random Python implementation and removing it
  afterwards? I believe that's something really worth fixing.
  
 
 That way was chosen to avoid an extensive patch I have already
 written. The maintainer of the package did not want to keep that
 around through version bumps which is understandable.

You again fail to see an interim solution which will solve the issue
without much trouble, similar to one used for multilib. You let
the build system work with the default implementation, then repeat
install for remaining implementations.

Of course, right now it's not supported by python-r1. I will think how
to solve it in a simple way.

-- 
Best regards,
Michał Górny


signature.asc

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

On Thu, 25 Oct 2012 21:19:37 +0200
hasufell hasuf...@gentoo.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 10/25/2012 06:41 PM, hasufell wrote:
  1. there is still no way to convert shebangs via python-r1 2. there
  are no equivalent functions to the python_get_* stuff which are
  sometimes necessary for broken build systems or test phases 3.
  there is no equivalent for python_mod_optimize. Having that in 
  distutils-r1 does not suffice for non-distutils packages where I
  might have to do that stuff manually. 5.
  distutils-r1_rename_scripts does not allow to specify a location 
  possibly breaking non-standard locations (e.g. games location) 6.
  How can I make the python dependencies optional, e.g. that 
  python:3.2 is only pulled in when gtk useflag for this package is
  set? 7. are we sure now that it's safe to ship the .pyc/.pyo files
  inside the package without side-effects? 8. how would I manually
  generate implementation-suffixed scripts without distutils-r1? 
  example: x11-misc/redshift-1.7-r1
  
 
 4. no equivalent to python_set_active_version
 
 feature request: let the ebuild developer choose a python
 implementation for the whole emerge process.
 
 usecase: packages not using distutils and not supporting multiple
 python abis, but detecting installed python in some way and working
 with all python:2.* slots.
 
 examples that come to my mind right now:
 games-strategy/freeorion
 games-action/openclonk
 net-im/pidgin
 app-office/libreoffice
 
 python_foreach_impl cannot fit that

Ah, sorry, I must have missed when we started supporting packages for
single Python implementation in python-r1. That probably happened when
nobody replied to the my mail requesting ideas on handling those
packages [1].

[1]:http://article.gmane.org/gmane.linux.gentoo.python/22

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-10-05 Thread Michał Górny

On Sat, 29 Sep 2012 10:53:29 +0200
Michał Górny mgo...@gentoo.org wrote:

 Instead of the floating patches and p-d-ng modifications I sent
 earlier, here are the two complete (so far, well, initial :P) eclasses
 for review.
 
 They are designed as 'mostly' drop-in python-distutils-ng replacement.

Conversion of all ebuilds in my overlay:
http://git.overlays.gentoo.org/gitweb/?p=dev/mgorny.git;a=commitdiff;h=c0c8c4ea

Conversion of all ebuilds in gx86:
https://bitbucket.org/mgorny/gx86-working-tree/changeset/6442b5d5b

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-10-01 Thread Fabian Groffen

On 30-09-2012 14:47:17 -0700, Brian Harring wrote:
  In the worst case it returns Bad marshalling data.
 
 Examples wanted for this.  If this occurs, that's a python bug- one 
 exception... portage (figures).  They install into a non 
 /usr/lib/python* location, meaning the .pyc/.pyo from py2.6 is 
 exposed/accessed for py2.7 for example.

https://bugs.gentoo.org/show_bug.cgi?id=300922

I doubt whether it's a Python bug, we have to mess with the files.  But
then again, I did some toying, and it seems Python doesn't care about
this (any more?).


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-10-01 Thread Brian Harring

On Mon, Oct 01, 2012 at 08:36:12AM +0200, Fabian Groffen wrote:
 On 30-09-2012 14:47:17 -0700, Brian Harring wrote:
   In the worst case it returns Bad marshalling data.
  
  Examples wanted for this.  If this occurs, that's a python bug- one 
  exception... portage (figures).  They install into a non 
  /usr/lib/python* location, meaning the .pyc/.pyo from py2.6 is 
  exposed/accessed for py2.7 for example.
 
 https://bugs.gentoo.org/show_bug.cgi?id=300922
 
 I doubt whether it's a Python bug, we have to mess with the files.  But
 then again, I did some toying, and it seems Python doesn't care about
 this (any more?).

Well, offhand that bug is pre EAPI3 (eapi3 was approved 01/18/10, and 
adoption was slow- lot of people skipped straight to eapi4) - so the 
mtime wouldn't have been guaranteed preserved for a long while.  
Meaning the bugs data I don't trust to be relevant due to timing, and 
age.

As you said, this needs revisiting- minimally, portage is screwing 
around contents there, and I don't trust the python eclass to /not/ be 
forcing a compileall after the fact anyways.

Suggest backing down the various protections for a full test, and 
resuming that bug- if you can replicate it, I'm definitely interested 
(dealt with this when it occurred for 2.3-2.4 for example).

~harring

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-10-01 Thread Marien Zwart

(pardon any awkward formatting, writing from webinterface instead of a
proper client. Please yell at me off-list or on irc if this post is
excessively broken.)

 https://bugs.gentoo.org/show_bug.cgi?id=300922

From that bug:

 - chpathtool does some simple heuristic to switch the build EPREFIX
   to the new target EPREFIX

 - python (seemingly) doesn't like when the pyc files are changed and *not* 
 regenerated.
   You will see the message: Bad marshalling data

I'm not sure if I'm interpreting this correctly, but it sounds as if
your chpathtool edits the .pyc file to replace the path? If yes: that
will indeed not work, as strings are stored length-prefixed. You
cannot sensibly edit .pyc files, you should normally just rewrite
them.

The .pyc/.pyo file store a version-dependent magic, the mtime of their
corresponding .py file, and (since recently) the size of the
correspondig .py file. If either changes the .pyc/.pyo is regenerated.
The magic does not normally change in released pythons, so that's not
much of a problem. The mtime is probably no longer a problem these
days either.

There used to be a more subtle problem: the python objects you import
have the path to their source embedded into them, and if you move the
.pyc/.pyo file around that path would be wrong, confusing some (mostly
debugging) tools (see http://bugs.python.org/issue1180193 ). This was
fixed fairly recently (in python 3, python 2.7 and python 2.6.2), so
it is probably no longer worth worrying about, but it's probably one
reason these files were handled this way in the past.

-- 
Marien Zwart (marienz)

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-10-01 Thread Fabian Groffen

On 01-10-2012 17:17:40 +0200, Marien Zwart wrote:
 There used to be a more subtle problem: the python objects you import
 have the path to their source embedded into them, and if you move the
 .pyc/.pyo file around that path would be wrong, confusing some (mostly
 debugging) tools (see http://bugs.python.org/issue1180193 ). This was
 fixed fairly recently (in python 3, python 2.7 and python 2.6.2), so
 it is probably no longer worth worrying about, but it's probably one
 reason these files were handled this way in the past.

This most likely is the reason why my tests with Python 2.7 worked fine
when I tinkered with the .pyc and/or moved it around.

Thanks

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-30 Thread Pacho Ramos

El sáb, 29-09-2012 a las 22:34 +0200, Michał Górny escribió:
 On Sat, 29 Sep 2012 21:20:00 +0200
 Pacho Ramos pa...@gentoo.org wrote:
 
  El sáb, 29-09-2012 a las 20:40 +0200, Michał Górny escribió:
   On Sat, 29 Sep 2012 17:45:07 +0200
   hasufell hasuf...@gentoo.org wrote:
   
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/29/2012 05:37 PM, Ian Stakenvicius wrote:
 
 There isn't so much a problem with the current python-distutils-ng 
 eclass but rather it's to expand it to a more comprehensive 
 replacement for both distutils and python eclasses.  In order to
 do that efficiently, most of the core functionality should be moved
 so that the new distutils is more like a wrapper to the new
 python.
 
 This could certainly be done by patching the existing eclass, but 
 mgorny wants to use new eclass names instead of keeping the
 current one.  Hence the rename.  I think that's about it..
 

In that case we are missing 95% of the features of python.eclass.
   
   Please list the features. Preferably, order them by usefulness, with
   exact use cases.
   
  
  Personally, I usually run:
  - python_clean_py-compile_files - Clean py-compile files to disable
  byte-compilation allowing us to drop all various ways of doing this that
  were living in the tree some time ago.
 
 Hmm, what's the problem with compiling them? Do you mean some case when
 the results of the compilation are different from the way done
 by the eclass?
 

Well, if I don't misremember, we currently prefer to compile them at
postinst phase instead of during src_compile, but maybe this is no
longer needed (no idea :( )

  - python_convert_shebangs - but, I guess this is handled in a different
  way in your eclass, no? :/
 
 Depends on what you need. To be honest, I haven't added any code for
 custom script handling yet, just the usual distutils case.
 
 A package which does not explicitly support multiple Python
 implementations is a completely different things, needing more
 discussion first and which actually may be handled through a separate
 eclass if most code of python-r1 proves useless for it.
 

I was thinking on a lot of packages still being only compatible with
python2... I guess will need to still use python.eclass for them then


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-30 Thread Fabian Groffen

On 30-09-2012 10:31:17 +0200, Pacho Ramos wrote:
   Personally, I usually run:
   - python_clean_py-compile_files - Clean py-compile files to disable
   byte-compilation allowing us to drop all various ways of doing this that
   were living in the tree some time ago.
  
  Hmm, what's the problem with compiling them? Do you mean some case when
  the results of the compilation are different from the way done
  by the eclass?
  
 
 Well, if I don't misremember, we currently prefer to compile them at
 postinst phase instead of during src_compile, but maybe this is no
 longer needed (no idea :( )

The files are indeed cache, and should be generated on the system that
installs the files, not the system that builds them.  They are currently
outside of VDB.  pyc files store the path to the original files, so
generating in ${ROOT} yields in wrong paths.  Python sometimes
regenerates the files when it runs.  It may as well just ignore them
(since they are newer but non-matching, unclear to me).  In the worst
case it returns Bad marshalling data.


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-30 Thread Pacho Ramos

El dom, 30-09-2012 a las 10:58 +0200, Fabian Groffen escribió:
 On 30-09-2012 10:31:17 +0200, Pacho Ramos wrote:
Personally, I usually run:
- python_clean_py-compile_files - Clean py-compile files to disable
byte-compilation allowing us to drop all various ways of doing this that
were living in the tree some time ago.
   
   Hmm, what's the problem with compiling them? Do you mean some case when
   the results of the compilation are different from the way done
   by the eclass?
   
  
  Well, if I don't misremember, we currently prefer to compile them at
  postinst phase instead of during src_compile, but maybe this is no
  longer needed (no idea :( )
 
 The files are indeed cache, and should be generated on the system that
 installs the files, not the system that builds them.  They are currently
 outside of VDB.  pyc files store the path to the original files, so
 generating in ${ROOT} yields in wrong paths.  Python sometimes
 regenerates the files when it runs.  It may as well just ignore them
 (since they are newer but non-matching, unclear to me).  In the worst
 case it returns Bad marshalling data.
 
 

Then, I guess having such function would still be useful :) Thanks for
the info


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-30 Thread Michał Górny

On Sun, 30 Sep 2012 10:58:06 +0200
Fabian Groffen grob...@gentoo.org wrote:

 On 30-09-2012 10:31:17 +0200, Pacho Ramos wrote:
Personally, I usually run:
- python_clean_py-compile_files - Clean py-compile files to disable
byte-compilation allowing us to drop all various ways of doing this that
were living in the tree some time ago.
   
   Hmm, what's the problem with compiling them? Do you mean some case when
   the results of the compilation are different from the way done
   by the eclass?
   
  
  Well, if I don't misremember, we currently prefer to compile them at
  postinst phase instead of during src_compile, but maybe this is no
  longer needed (no idea :( )
 
 The files are indeed cache, and should be generated on the system that
 installs the files, not the system that builds them.  They are currently
 outside of VDB.  pyc files store the path to the original files, so
 generating in ${ROOT} yields in wrong paths.  Python sometimes
 regenerates the files when it runs.  It may as well just ignore them
 (since they are newer but non-matching, unclear to me).  In the worst
 case it returns Bad marshalling data.

Hmm, so python-distutils-ng was wrong from the beginning and nobody
cared to point it out?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-30 Thread Fabian Groffen

On 30-09-2012 15:28:47 +0200, Michał Górny wrote:
  The files are indeed cache, and should be generated on the system that
  installs the files, not the system that builds them.  They are currently
  outside of VDB.  pyc files store the path to the original files, so
  generating in ${ROOT} yields in wrong paths.  Python sometimes
  regenerates the files when it runs.  It may as well just ignore them
  (since they are newer but non-matching, unclear to me).  In the worst
  case it returns Bad marshalling data.
 
 Hmm, so python-distutils-ng was wrong from the beginning and nobody
 cared to point it out?

I'm not reviewing each and everything in detail, sorry.  It's just
that Pacho raised the point in this thread that made me recall the
above.


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-30 Thread Michał Górny

On Sun, 30 Sep 2012 10:58:06 +0200
Fabian Groffen grob...@gentoo.org wrote:

 On 30-09-2012 10:31:17 +0200, Pacho Ramos wrote:
Personally, I usually run:
- python_clean_py-compile_files - Clean py-compile files to disable
byte-compilation allowing us to drop all various ways of doing this that
were living in the tree some time ago.
   
   Hmm, what's the problem with compiling them? Do you mean some case when
   the results of the compilation are different from the way done
   by the eclass?
   
  
  Well, if I don't misremember, we currently prefer to compile them at
  postinst phase instead of during src_compile, but maybe this is no
  longer needed (no idea :( )
 
 The files are indeed cache, and should be generated on the system that
 installs the files, not the system that builds them.  They are currently
 outside of VDB.  pyc files store the path to the original files, so
 generating in ${ROOT} yields in wrong paths.  Python sometimes
 regenerates the files when it runs.  It may as well just ignore them
 (since they are newer but non-matching, unclear to me).  In the worst
 case it returns Bad marshalling data.

I'm afraid you are wrong here.

I've just tested an ebuild using distutils (flaggie) and autotools
(pygobject) and both install .pyc files with correct paths (i.e. with
DESTDIR stripped).

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-30 Thread Michał Górny

On Sat, 29 Sep 2012 22:48:00 +0200
hasufell hasuf...@gentoo.org wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/29/2012 08:39 PM, Michał Górny wrote:
On Sat, 29 Sep 2012 16:37:15 +0200 Dirkjan Ochtman d...@gentoo.org
wrote:

On Sat, Sep 29, 2012 at 4:26 PM, hasufell hasuf...@gentoo.org
wrote:
That still does not explain the reasons why this work was
initiated.

If there is any way to fix the current eclass, that should be
preferred.

I tend to agree. Michał, let me first say I value the time you
have invested to make the eclasses better. However, at this point
I have a strong feeling that we have more people willing to write
code to fix things than we have people building consensus on
what features/policies/mechanisms we need to make it easy to
write high-quality ebuilds for Python/distutils. I would prefer
discussions on problems that the current ebuilds have and
discussions on how to solve them, not at the code level, but that
the mechanism level.

The main issue: noone wants to even touch python.eclass or
anything nearby.

The second issue: python-distutils-ng isn't good enough. It has
too many things hard-wired. I think I have already pointed enough
problems with it. Not that many people cared to respond.

It's sad that people don't care to respond when you point the
issues out but then complain when you do something to fix them.

Did you CC gentoo-dev? I cannot find the tread.

Maybe. People interested in Python should be either on the Python ml
or on the python@ alias, I believe.

[example needed]

I meant that not all tree ebuilds use the same python-eclass
implementation which IS a problem. Adding another implementation does
not really improve that situation.

As long as they can inter-operate correctly, I don't see any problem.

Please list the features. Preferably, order them by usefulness,
with exact use cases.

As I said, I think the python herd already did a list on this.

Btw. could you give exact examples on how to convert widely used
python ebuilds with your eclasses?
E.g. dev-python/pygobject dev-python/setuptools or dev-libs/boost?

I have prepared and tested an ebuild for pygobject and setuptools here:

http://git.overlays.gentoo.org/gitweb/?p=dev/mgorny.git;a=tree;f=dev-python;h=557b96c041bb6da969574dd75dcdfd4022ba636b;hb=refs/heads/python-r1

I will take a look at boost a while later, since I have to have much
more time to compile it :P.

How can I convert shebangs consistently and recursively?

Converting shebangs applies to packages supporting multiple Python
implementations or those not doing so?

--
Best regards,
Michał Górny

signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-30 Thread Fabian Groffen

I'm on the list, obviously, so PLEASE stop Cc-ing me!

On 30-09-2012 15:57:16 +0200, Michał Górny wrote:
  The files are indeed cache, and should be generated on the system that
  installs the files, not the system that builds them.  They are currently
  outside of VDB.  pyc files store the path to the original files, so
  generating in ${ROOT} yields in wrong paths.  Python sometimes
  regenerates the files when it runs.  It may as well just ignore them
  (since they are newer but non-matching, unclear to me).  In the worst
  case it returns Bad marshalling data.
 
 I'm afraid you are wrong here.
 
 I've just tested an ebuild using distutils (flaggie) and autotools
 (pygobject) and both install .pyc files with correct paths (i.e. with
 DESTDIR stripped).

Could be, if it uses relative paths, but they won't be absolute then
either.  From some experiments I did, I saw Python ignoring wrong paths
(entire cache?), or updating the pyc/pyo files.  Regardless whether or
not the data is wrong, the discussion is more if it hurts (and makes
sense).

Back then, we found it hurt us (Bad marshalling data) when using
binpkgs.  Not sure if it still does today with Python 2.7.  Somehow we
reached a consensus with the Python maintainer at that time that cache
stuff shouldn't be in VDB, also because it depends on system and perhaps
Python version.  Since embedded systems might not even want it (it's
just cache afterall, wasting their sometimes precious disk space), it
had to be out of the package contents for them as well.

That's how we came to the situation as it was before python eclass
rewrites.  I'd much prefer Python to write its cache to some
/var/cache/python dir so it can create whatever it wants, but on a
place which is not of any concern, as its obvious one can throw it away,
and doesn't pollute the live fs.  But Python doesn't work that way.

Whatever the new way will be, for whatever reason, please make sure it
is consistent.  And be aware that this doesn't just mean changing
eclasses, since this rule is effectuated in certain ebuilds too
(dev-lang/python itself being the most obvious example).


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-30 Thread Zac Medico

On 09/30/2012 07:12 AM, Fabian Groffen wrote:
 Back then, we found it hurt us (Bad marshalling data) when using
 binpkgs.  Not sure if it still does today with Python 2.7.  Somehow we
 reached a consensus with the Python maintainer at that time that cache
 stuff shouldn't be in VDB, also because it depends on system and perhaps
 Python version.  Since embedded systems might not even want it (it's
 just cache afterall, wasting their sometimes precious disk space), it
 had to be out of the package contents for them as well.

They can use INSTALL_MASK=*.py[co] if they need to. In portage we have
a default COLLISION_IGNORE=*.py[co] setting, so that there are no
related issues with file collisions for *.py[co] if the user removes the
INSTALL_MASK setting later.
-- 
Thanks,
Zac

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-30 Thread Brian Harring

On Sun, Sep 30, 2012 at 10:58:06AM +0200, Fabian Groffen wrote:
 On 30-09-2012 10:31:17 +0200, Pacho Ramos wrote:
Personally, I usually run:
- python_clean_py-compile_files - Clean py-compile files to disable
byte-compilation allowing us to drop all various ways of doing this that
were living in the tree some time ago.
   
   Hmm, what's the problem with compiling them? Do you mean some case when
   the results of the compilation are different from the way done
   by the eclass?
   
  
  Well, if I don't misremember, we currently prefer to compile them at
  postinst phase instead of during src_compile, but maybe this is no
  longer needed (no idea :( )
 
 The files are indeed cache, and should be generated on the system that
 installs the files, not the system that builds them.  They are currently
 outside of VDB.  pyc files store the path to the original files, so
 generating in ${ROOT} yields in wrong paths.  Python sometimes
 regenerates the files when it runs.  It may as well just ignore them
 (since they are newer but non-matching, unclear to me).

.pyc should be compatible within slotted python versions; 
recompilation occurs if .pyc/.pyo mtime differs from the originating 
.py.  Via EAPI=3 mtime gurantees, that should be addressed- below 
that, compilation via pkg_postinst is necessary due to the lack of 
mtime guarantees.

 In the worst case it returns Bad marshalling data.

Examples wanted for this.  If this occurs, that's a python bug- one 
exception... portage (figures).  They install into a non 
/usr/lib/python* location, meaning the .pyc/.pyo from py2.6 is 
exposed/accessed for py2.7 for example.

That said, a .pyc/.pyo from an older python version causing a blow up 
in a differing python version hasn't occurred since the 2.3 - 2.4 
transition (if memory serves).

Either way, examples desired please.
~harring

[gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

Hello,

Instead of the floating patches and p-d-ng modifications I sent
earlier, here are the two complete (so far, well, initial :P) eclasses
for review.

They are designed as 'mostly' drop-in python-distutils-ng replacement.

-- 
Best regards,
Michał Górny
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: python-r1
# @MAINTAINER:
# Python herd pyt...@gentoo.org
# @AUTHOR:
# Author: MichaÅ GÃ³rny mgo...@gentoo.org
# Based on work of: Krzysztof Pawlik nelch...@gentoo.org
# @BLURB: A common, simple eclass for Python packages.
# @DESCRIPTION:
# A common eclass providing helper functions to build and install
# packages supporting being installed for multiple Python
# implementations.
#
# This eclass sets correct IUSE and REQUIRED_USE. It exports PYTHON_DEPS
# and PYTHON_USEDEP so you can create correct dependencies for your
# package easily. It also provides methods to easily run a command for
# each enabled Python implementation and duplicate the sources for them.

case ${EAPI} in
0|1|2|3)
die Unsupported EAPI=${EAPI} (too old) for ${ECLASS}
;;
4)
# EAPI=4 needed for REQUIRED_USE
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac

# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
# @INTERNAL
# @DESCRIPTION:
# All supported Python implementations, most preferred last.
_PYTHON_ALL_IMPLS=(
jython2_5
pypy1_8 pypy1_9
python3_1 python3_2
python2_5 python2_6 python2_7
)

# @ECLASS-VARIABLE: PYTHON_COMPAT
# @DESCRIPTION:
# This variable contains a space separated list of Python
# implementations a package supports. It must be set before
# the `inherit' call.  The default is to enable all implementations.
#
# PYTHON_COMPAT can be either a scalar or an array. If it's a scalar,
# the eclass will implicitly convert it to an array.
: ${PYTHON_COMPAT:=${_PYTHON_ALL_IMPLS[@]}}

# @ECLASS-VARIABLE: PYTHON_REQ_USE
# @DEFAULT_UNSET
# @DESCRIPTION:
# The list of USEflags required to be enabled on the chosen Python
# implementations, formed as a USE-dependency string. It should be valid
# for all implementations in PYTHON_COMPAT, so it may be necessary to
# use USE defaults.
#
# Example:
# @CODE
# PYTHON_REQ_USE=gdbm,ncurses(-)?
# @CODE
#
# Will cause the Python dependencies to look like:
# @CODE
# python_targets_pythonX_Y? (
#   dev-lang/python:X_Y[gdbm,ncurses(-)?] )
# @CODE

# @ECLASS-VARIABLE: PYTHON_DEPS
# @DESCRIPTION:
# This is an eclass-generated Python dependency string for all
# implementations listed in PYTHON_COMPAT. It should be used
# in RDEPEND and/or DEPEND like:
#
# @CODE
# RDEPEND=${PYTHON_DEPS}
#   dev-foo/mydep
# DEPEND=${RDEPEND}
# @CODE

# @ECLASS-VARIABLE: PYTHON_USEDEP
# @DESCRIPTION:
# This is an eclass-generated USE-dependency string which can be used to
# depend on another Python package being built for the same Python
# implementations. It should be used like:
#
# @CODE
# RDEPEND=dev-python/foo[${PYTHON_USEDEP}]
# @CODE

PYTHON_COMPAT=( ${PYTHON_COMPAT[@]} )

_python_set_globals() {
local flags=( ${PYTHON_COMPAT[@]/#/python_targets_} )
local optflags=${flags[@]/%/?}

IUSE=${flags[*]}
REQUIRED_USE=|| ( ${flags[*]} )
PYTHON_USEDEP=${optflags// /,}

PYTHON_DEPS=
local i
for i in ${PYTHON_COMPAT[@]}; do
local d
case ${i} in
python*)
d='dev-lang/python';;
jython*)
d='dev-java/jython';;
pypy*)
d='dev-python/pypy';;
*)
die Invalid implementation: ${i}
esac

local v=${i##*[a-z]}
local usestr
[[ ${PYTHON_REQ_USE} ]]  usestr=[${PYTHON_REQ_USE}]
PYTHON_DEPS+= python_targets_${i}? (
${d}:${v/_/.}${usestr} )
done
}
_python_set_globals

# @FUNCTION: python_get_PYTHON
# @USAGE: impl
# @DESCRIPTION:
# Get the Python executable name for the given implementation. Please
# note that this this function returns the 'basename' only.
# If using it for a hashbang, please use #!/usr/bin/env.
python_get_PYTHON() {
local impl=${1/_/.}

case ${impl} in
python*|jython*)
echo ${impl}
;;
pypy*)
echo pypy-c${impl#pypy}
;;
*)
die Invalid argument to python_get_PYTHON: ${1}
;;
esac
}

# @FUNCTION: python_copy_sources
# @DESCRIPTION:
# Create a single copy of the package sources (${S}) for each enabled
# Python implementation.
python_copy_sources() {
local

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-29 Thread Tomáš Chvátal

2012/9/29 Michał Górny mgo...@gentoo.org:
 Hello,

 Instead of the floating patches and p-d-ng modifications I sent
 earlier, here are the two complete (so far, well, initial :P) eclasses
 for review.

 They are designed as 'mostly' drop-in python-distutils-ng replacement.

Hi,

the eclasses look pretty, so good job,
just one question tho, would it be possible to use more
debug-something calls so the log file would be populated automatically
with whats going on (same like eg git-2 eclass)?

Cheers

Tom

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-29 Thread Markos Chandras

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/29/2012 09:53 AM, Micha? Górny wrote:
 Hello,
 
 Instead of the floating patches and p-d-ng modifications I sent 
 earlier, here are the two complete (so far, well, initial :P)
 eclasses for review.
 
 They are designed as 'mostly' drop-in python-distutils-ng
 replacement.
 
Hi,

Are you saying that you are going to remove the python-distutils-ng
eclass in favour of the new eclasses? I don't quite understand the
reasons to be honest.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBCgAGBQJQZstvAAoJEPqDWhW0r/LCC4gQAJmmseSriDS8ahCnkUNBm+61
NGxGijft0zE8qFvdLDH+koQ+ym8/KrMvZcp5U1pLEGDOBVXYj33nOQ9kA24rKBvz
Ro2Ydvxcj0Zo/nXGmLB0Mr9IaW4oWY8A16iY24qCpmPV1AWJXdoB0gdtXcDS4MmD
+LT19sRMqJstjUXbS02xrWS8lrbcPxVqVkfAPtFo82+/rtceHu+ymSVgJwkTQgBV
tKLdI16hK3x9pvceMgaYlC1W32yWq3YUOn3mvFjh4EjANrZ64ED1Q3A+QCYe
pUSwx3BGTZnQK6WQtSer/8O/oW7FoR5DooJTNsg1xrPTEdPd79D28TThy3ollACP
F5GtKyZO5gFK4SxQdbYfo9Su1Wa0XYybLHihnJDUVHuF2/AchSFW4CtGHfxQ4A0g
HWtEgdfRzk5kTUwR2LUhrisei3c6qpB0KGcZZCpi5FF9s150Si2wlKi2PbffAfil
0vLML3mnZnez5bWzPB1DqHf5eWdM00/BFaG4IQJkipwC3jJQ/rye9ruAv2UTM/Rs
UH6FQCfTRbScaf0E2WCGMIr33//HsIzy7KPAMAyfJWmxsBGwYHtouci7rQgUZIxn
+MdLQuzTYkUgybdnkhLmEeThl8coNwVeEzXwoQZGlciszz6cniSu66WbEEAUxgTP
5F9+vTb5XF1Jq+ZXrrb8
=7EZ5
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

On Sat, 29 Sep 2012 12:00:18 +0200
Tomáš Chvátal tomas.chva...@gmail.com wrote:

 2012/9/29 Michał Górny mgo...@gentoo.org:
  Hello,
 
  Instead of the floating patches and p-d-ng modifications I sent
  earlier, here are the two complete (so far, well, initial :P) eclasses
  for review.
 
  They are designed as 'mostly' drop-in python-distutils-ng replacement.
 
 Hi,
 
 the eclasses look pretty, so good job,
 just one question tho, would it be possible to use more
 debug-something calls so the log file would be populated automatically
 with whats going on (same like eg git-2 eclass)?

Can do. Was just lazy ;P.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

On Sat, 29 Sep 2012 12:00:18 +0200
Tomáš Chvátal tomas.chva...@gmail.com wrote:

 2012/9/29 Michał Górny mgo...@gentoo.org:
  Hello,
 
  Instead of the floating patches and p-d-ng modifications I sent
  earlier, here are the two complete (so far, well, initial :P) eclasses
  for review.
 
  They are designed as 'mostly' drop-in python-distutils-ng replacement.
 
 Hi,
 
 the eclasses look pretty, so good job,
 just one question tho, would it be possible to use more
 debug-something calls so the log file would be populated automatically
 with whats going on (same like eg git-2 eclass)?

Try now :P.

-- 
Best regards,
Michał Górny
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: python-r1
# @MAINTAINER:
# Python herd pyt...@gentoo.org
# @AUTHOR:
# Author: MichaÅ GÃ³rny mgo...@gentoo.org
# Based on work of: Krzysztof Pawlik nelch...@gentoo.org
# @BLURB: A common, simple eclass for Python packages.
# @DESCRIPTION:
# A common eclass providing helper functions to build and install
# packages supporting being installed for multiple Python
# implementations.
#
# This eclass sets correct IUSE and REQUIRED_USE. It exports PYTHON_DEPS
# and PYTHON_USEDEP so you can create correct dependencies for your
# package easily. It also provides methods to easily run a command for
# each enabled Python implementation and duplicate the sources for them.

case ${EAPI} in
0|1|2|3)
die Unsupported EAPI=${EAPI} (too old) for ${ECLASS}
;;
4)
# EAPI=4 needed for REQUIRED_USE
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac

# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
# @INTERNAL
# @DESCRIPTION:
# All supported Python implementations, most preferred last.
_PYTHON_ALL_IMPLS=(
jython2_5
pypy1_8 pypy1_9
python3_1 python3_2
python2_5 python2_6 python2_7
)

# @ECLASS-VARIABLE: PYTHON_COMPAT
# @DESCRIPTION:
# This variable contains a space separated list of Python
# implementations a package supports. It must be set before
# the `inherit' call.  The default is to enable all implementations.
#
# PYTHON_COMPAT can be either a scalar or an array. If it's a scalar,
# the eclass will implicitly convert it to an array.
: ${PYTHON_COMPAT:=${_PYTHON_ALL_IMPLS[@]}}

# @ECLASS-VARIABLE: PYTHON_REQ_USE
# @DEFAULT_UNSET
# @DESCRIPTION:
# The list of USEflags required to be enabled on the chosen Python
# implementations, formed as a USE-dependency string. It should be valid
# for all implementations in PYTHON_COMPAT, so it may be necessary to
# use USE defaults.
#
# Example:
# @CODE
# PYTHON_REQ_USE=gdbm,ncurses(-)?
# @CODE
#
# Will cause the Python dependencies to look like:
# @CODE
# python_targets_pythonX_Y? (
#   dev-lang/python:X_Y[gdbm,ncurses(-)?] )
# @CODE

# @ECLASS-VARIABLE: PYTHON_DEPS
# @DESCRIPTION:
# This is an eclass-generated Python dependency string for all
# implementations listed in PYTHON_COMPAT. It should be used
# in RDEPEND and/or DEPEND like:
#
# @CODE
# RDEPEND=${PYTHON_DEPS}
#   dev-foo/mydep
# DEPEND=${RDEPEND}
# @CODE

# @ECLASS-VARIABLE: PYTHON_USEDEP
# @DESCRIPTION:
# This is an eclass-generated USE-dependency string which can be used to
# depend on another Python package being built for the same Python
# implementations. It should be used like:
#
# @CODE
# RDEPEND=dev-python/foo[${PYTHON_USEDEP}]
# @CODE

PYTHON_COMPAT=( ${PYTHON_COMPAT[@]} )

_python_set_globals() {
local flags=( ${PYTHON_COMPAT[@]/#/python_targets_} )
local optflags=${flags[@]/%/?}

IUSE=${flags[*]}
REQUIRED_USE=|| ( ${flags[*]} )
PYTHON_USEDEP=${optflags// /,}

PYTHON_DEPS=
local i
for i in ${PYTHON_COMPAT[@]}; do
local d
case ${i} in
python*)
d='dev-lang/python';;
jython*)
d='dev-java/jython';;
pypy*)
d='dev-python/pypy';;
*)
die Invalid implementation: ${i}
esac

local v=${i##*[a-z]}
local usestr
[[ ${PYTHON_REQ_USE} ]]  usestr=[${PYTHON_REQ_USE}]
PYTHON_DEPS+= python_targets_${i}? (
${d}:${v/_/.}${usestr} )
done
}
_python_set_globals

# @FUNCTION: python_get_PYTHON
# @USAGE: impl
# @DESCRIPTION:
# Get the Python executable name for the given implementation. Please
# note that this this function returns the 'basename' only.
# If using it for a hashbang, please use #!/usr/bin/env.
python_get_PYTHON() {
debug-print-function ${FUNCNAME} ${@}

local impl=${1/_/.}
local ret

case ${impl} in
python*|jython*)
ret=${impl}

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

On Sat, 29 Sep 2012 11:20:31 +0100
Markos Chandras hwoar...@gentoo.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 On 09/29/2012 09:53 AM, Micha? Górny wrote:
  Hello,
  
  Instead of the floating patches and p-d-ng modifications I sent 
  earlier, here are the two complete (so far, well, initial :P)
  eclasses for review.
  
  They are designed as 'mostly' drop-in python-distutils-ng
  replacement.
  
 Hi,
 
 Are you saying that you are going to remove the python-distutils-ng
 eclass in favour of the new eclasses? I don't quite understand the
 reasons to be honest.

The reason is simple -- I can't fix it without changing the API.
Changing the API on a live eclass is confusing, and considering that it
is not used by many packages, it's easier to lastrite it.

Also, this fixes the name not to have any '-ng' nor '-ds9'.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/29/2012 12:49 PM, Michał Górny wrote:
 On Sat, 29 Sep 2012 11:20:31 +0100 Markos Chandras
 hwoar...@gentoo.org wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 On 09/29/2012 09:53 AM, Micha? Górny wrote:
 Hello,
 
 Instead of the floating patches and p-d-ng modifications I sent
  earlier, here are the two complete (so far, well, initial :P) 
 eclasses for review.
 
 They are designed as 'mostly' drop-in python-distutils-ng 
 replacement.
 
 Hi,
 
 Are you saying that you are going to remove the
 python-distutils-ng eclass in favour of the new eclasses? I don't
 quite understand the reasons to be honest.
 
 The reason is simple -- I can't fix it without changing the API. 
 Changing the API on a live eclass is confusing, and considering
 that it is not used by many packages, it's easier to lastrite it.
 
 Also, this fixes the name not to have any '-ng' nor '-ds9'.
 

What are the reasons to change the API in the first place? There has
to be a good reason, cause this will involve yet another migration of
many ebuilds. I don't see any bugreports.

I fear this will cause more confusion, i.e. some ebuilds using the old
distutils, some using python-distutils-ng and some using distutils-r1
resulting in weird tree behavior.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQZvxsAAoJEFpvPKfnPDWzL1IH/iaChrfPET4KArZzaViXJjlL
4pM2tmgByJNAgtFjwLwz3c6lqdJGAV8Uf4VpPTec+Z7lj0v0SDj04YI63CgFZ2N/
R7edGAoJdGOFDv/oOY+bP38PeWpnuguOvEaKI8EEqaJgLne29wPEQ7+KcWe8M6hM
tA41lIIFpK2PN+kIHdItbSl8aRZmm9NorfUCukFfs1odwV+C0B3rP4mJZQW+TnbR
DmDqFCFQF/r1k+n17wARqvcCL+hBqs/CvTG7K8Z/mNWD/Dove1vMB1ir8p8KnYSO
TULgpcVEK4VuXjHrccLhmO4ODWZiXn/yWKws3z+XmRwIwBB7m9IhC8G32aeyqoE=
=gU6H
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-29 Thread Ian Stakenvicius

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 29/09/12 09:49 AM, hasufell wrote:
 On 09/29/2012 12:49 PM, Michał Górny wrote:
 On Sat, 29 Sep 2012 11:20:31 +0100 Markos Chandras 
 hwoar...@gentoo.org wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 On 09/29/2012 09:53 AM, Micha? Górny wrote:
 Hello,
 
 Instead of the floating patches and p-d-ng modifications I
 sent earlier, here are the two complete (so far, well,
 initial :P) eclasses for review.
 
 They are designed as 'mostly' drop-in python-distutils-ng 
 replacement.
 
 Hi,
 
 Are you saying that you are going to remove the 
 python-distutils-ng eclass in favour of the new eclasses? I
 don't quite understand the reasons to be honest.
 
 The reason is simple -- I can't fix it without changing the API.
  Changing the API on a live eclass is confusing, and considering 
 that it is not used by many packages, it's easier to lastrite
 it.
 
 Also, this fixes the name not to have any '-ng' nor '-ds9'.
 
 
 What are the reasons to change the API in the first place? There
 has to be a good reason, cause this will involve yet another
 migration of many ebuilds. I don't see any bugreports.
 
 I fear this will cause more confusion, i.e. some ebuilds using the
 old distutils, some using python-distutils-ng and some using
 distutils-r1 resulting in weird tree behavior.
 

Given that at present, distutils-r1 and python-distutils-ng have
identical end-results, I think that the introduction of distutils-r1
to the tree should also involve a sed against all the existing ebuilds
using python-distutils-ng to move them to the new eclass.  Then
python-distutils-ng only needs to remain to support overlays.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBnA1YACgkQ2ugaI38ACPBtCgD/UXW804+tsTOnI0RtfWfhiewK
a0W9DXplPRprWYZg4mQBAIWbRf+AJDrIqGvELiwt3p0FXChbCYypHDmm3tb8ljxL
=isBB
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/29/2012 04:19 PM, Ian Stakenvicius wrote:
 On 29/09/12 09:49 AM, hasufell wrote:
 On 09/29/2012 12:49 PM, Michał Górny wrote:
 On Sat, 29 Sep 2012 11:20:31 +0100 Markos Chandras 
 hwoar...@gentoo.org wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 On 09/29/2012 09:53 AM, Micha? Górny wrote:
 Hello,
 
 Instead of the floating patches and p-d-ng modifications I 
 sent earlier, here are the two complete (so far, well, 
 initial :P) eclasses for review.
 
 They are designed as 'mostly' drop-in python-distutils-ng 
 replacement.
 
 Hi,
 
 Are you saying that you are going to remove the 
 python-distutils-ng eclass in favour of the new eclasses? I 
 don't quite understand the reasons to be honest.
 
 The reason is simple -- I can't fix it without changing the
 API. Changing the API on a live eclass is confusing, and
 considering that it is not used by many packages, it's easier
 to lastrite it.
 
 Also, this fixes the name not to have any '-ng' nor '-ds9'.
 
 
 What are the reasons to change the API in the first place? There 
 has to be a good reason, cause this will involve yet another 
 migration of many ebuilds. I don't see any bugreports.
 
 I fear this will cause more confusion, i.e. some ebuilds using
 the old distutils, some using python-distutils-ng and some using 
 distutils-r1 resulting in weird tree behavior.
 
 
 Given that at present, distutils-r1 and python-distutils-ng have 
 identical end-results, I think that the introduction of
 distutils-r1 to the tree should also involve a sed against all the
 existing ebuilds using python-distutils-ng to move them to the new
 eclass.  Then python-distutils-ng only needs to remain to support
 overlays.
 
 

That still does not explain the reasons why this work was initiated.

If there is any way to fix the current eclass, that should be preferred.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQZwUtAAoJEFpvPKfnPDWz+g4IAIL0eFfX6rMHKBxtNkCGt7yo
dnPMiAjlbRwDVkpCBnorATwLpnHhsRfsHtHXkQrNXWzgGvSgOETpvGzmFgvPzr4L
lvOs3ND8BFZz3OiQuw3K2GrwInbQCXg1oFlKdBuLOom7WxtePVXeJsK3Ck4coGcH
NIfYlQNLaISp0CvUhGg3yF6/PjSCZ9vwfIN7muY1OVspE0DWXCRIZoOs623RixTS
cwzFRIdlxeJgw+JEuLN8wSsXe+Ir3bmmFOiRF+FD6LzjoYdh0xRyGX6Qgg974F7f
yb2aOT2MCMANWrMgdYiNuRZGJNvUagZ78PRIGHWNw+PzDaNC3jXqrTBsGpkk2Fc=
=azK1
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-29 Thread Dirkjan Ochtman

On Sat, Sep 29, 2012 at 4:26 PM, hasufell hasuf...@gentoo.org wrote:
 That still does not explain the reasons why this work was initiated.

 If there is any way to fix the current eclass, that should be preferred.

I tend to agree. Michał, let me first say I value the time you have
invested to make the eclasses better. However, at this point I have a
strong feeling that we have more people willing to write code to fix
things than we have people building consensus on what
features/policies/mechanisms we need to make it easy to write
high-quality ebuilds for Python/distutils. I would prefer discussions
on problems that the current ebuilds have and discussions on how to
solve them, not at the code level, but that the mechanism level.

Cheers,

Dirkjan

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-29 Thread Ian Stakenvicius

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 29/09/12 10:26 AM, hasufell wrote:
 On 09/29/2012 04:19 PM, Ian Stakenvicius wrote:
 On 29/09/12 09:49 AM, hasufell wrote:
 On 09/29/2012 12:49 PM, Michał Górny wrote:
 On Sat, 29 Sep 2012 11:20:31 +0100 Markos Chandras 
 hwoar...@gentoo.org wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 On 09/29/2012 09:53 AM, Micha? Górny wrote:
 Hello,
 
 Instead of the floating patches and p-d-ng modifications
 I sent earlier, here are the two complete (so far, well,
  initial :P) eclasses for review.
 
 They are designed as 'mostly' drop-in python-distutils-ng
  replacement.
 
 Hi,
 
 Are you saying that you are going to remove the 
 python-distutils-ng eclass in favour of the new eclasses? I
  don't quite understand the reasons to be honest.
 
 The reason is simple -- I can't fix it without changing the 
 API. Changing the API on a live eclass is confusing, and 
 considering that it is not used by many packages, it's
 easier to lastrite it.
 
 Also, this fixes the name not to have any '-ng' nor '-ds9'.
 
 
 What are the reasons to change the API in the first place?
 There has to be a good reason, cause this will involve yet
 another migration of many ebuilds. I don't see any bugreports.
 
 I fear this will cause more confusion, i.e. some ebuilds using 
 the old distutils, some using python-distutils-ng and some
 using distutils-r1 resulting in weird tree behavior.
 
 
 Given that at present, distutils-r1 and python-distutils-ng have
  identical end-results, I think that the introduction of 
 distutils-r1 to the tree should also involve a sed against all
 the existing ebuilds using python-distutils-ng to move them to
 the new eclass.  Then python-distutils-ng only needs to remain to
 support overlays.
 
 
 
 That still does not explain the reasons why this work was
 initiated.
 
 If there is any way to fix the current eclass, that should be
 preferred.
 

There isn't so much a problem with the current python-distutils-ng
eclass but rather it's to expand it to a more comprehensive
replacement for both distutils and python eclasses.  In order to do
that efficiently, most of the core functionality should be moved so
that the new distutils is more like a wrapper to the new python.

This could certainly be done by patching the existing eclass, but
mgorny wants to use new eclass names instead of keeping the current
one.  Hence the rename.  I think that's about it..
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBnFbcACgkQ2ugaI38ACPAirwD/SqHvaJfc73pYzxSoow0ORPJY
mSe1aS9kNk7SGT4ey1EA/jLPc1+of8Rwh3BFxeGfk0H1Go4mr/AbqhLDPnkxO2Sn
=QUTg
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/29/2012 05:37 PM, Ian Stakenvicius wrote:
 
 There isn't so much a problem with the current python-distutils-ng 
 eclass but rather it's to expand it to a more comprehensive 
 replacement for both distutils and python eclasses.  In order to
 do that efficiently, most of the core functionality should be moved
 so that the new distutils is more like a wrapper to the new
 python.
 
 This could certainly be done by patching the existing eclass, but 
 mgorny wants to use new eclass names instead of keeping the
 current one.  Hence the rename.  I think that's about it..
 

In that case we are missing 95% of the features of python.eclass.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQZxeDAAoJEFpvPKfnPDWzmRAH+wThUWb1jzE+jFUbTeuByKca
a4wVAFWy8ruGIQI82+/9bY5zZqitiqU1MijAixbdgwLwGeFurD6UBx+7vAUJ01YR
G5ALZOqxK7js0TJ3pv9wXiNihhoGjXGby+8MtbUogJ5mqB9r9vYaZaOUMRpaOpkg
VOgpVXX2YGixuder8JRo2snVQkd+hpMoZ3EI4w0EaSofhNGEV8f1BP27OUNgts1K
iH3EuVU3CF5STqGK4Fo7wwNwhsbzkQbMBVe/V9zBvJQEZyUVU9EuQ0+bvnedzAMB
PPgEXmNdxxbALxIR3xSpi7o/dyl21feJK968C9ObPpwMMloaNfQewQYB0MNPrY4=
=CEMA
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/29/2012 05:37 PM, Ian Stakenvicius wrote:
 
 There isn't so much a problem with the current python-distutils-ng 
 eclass but rather it's to expand it to a more comprehensive 
 replacement for both distutils and python eclasses.  In order to
 do that efficiently, most of the core functionality should be moved
 so that the new distutils is more like a wrapper to the new
 python.
 
 This could certainly be done by patching the existing eclass, but 
 mgorny wants to use new eclass names instead of keeping the
 current one.  Hence the rename.  I think that's about it..
 

To be a bit more precise:

if we really want to replace python.eclass we should start the new
eclass by gathering a list of features the python herd and developers
want. I think there already is something like that, no?

I don't see a point in adding a draft-eclass to the tree.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQZxguAAoJEFpvPKfnPDWz29QH/2mylpPs2759z27RKqvmdGh8
X8bV+CMRqWBPl1+blXpGlX9Bf6Er7MRQD1XarqpgvT+1ALhJYL0SZO/MA5DTxvkJ
1EdhdlIVK2ew6UTOmH0jin+wSuspBE1ZpLJCLLWQ94PQgLScaVmAj+XWMLuCbSOF
GfKW1thACamIKl3ej1foxMzD9mtSvufqI+eZQd0V341jHR1v5JF8LeqfC3C8c8nR
AalRvqbh1QltzcX7ao8wWeq4cYUAGrYACrjQqiEtEnMuUkk2upQMzdjt0I41D5vT
oOJtlsk742SLdE4ZIHCsXbjeEOKaFiLBlDjHvcvkWl4MkbKQ6pGpnsTYSpDm8+k=
=iY6x
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-29 Thread Ian Stakenvicius

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 29/09/12 11:45 AM, hasufell wrote:
 On 09/29/2012 05:37 PM, Ian Stakenvicius wrote:
 
 There isn't so much a problem with the current
 python-distutils-ng eclass but rather it's to expand it to a more
 comprehensive replacement for both distutils and python eclasses.
 In order to do that efficiently, most of the core functionality
 should be moved so that the new distutils is more like a wrapper
 to the new python.
 
 This could certainly be done by patching the existing eclass, but
  mgorny wants to use new eclass names instead of keeping the 
 current one.  Hence the rename.  I think that's about it..
 
 
 In that case we are missing 95% of the features of python.eclass.
 

Aha, but do we really -need- 95% of the features?  :)   Personally
(this is my investment in this project) I'd just like to see
non-distutils ebuilds needing python support using PYTHON_TARGETS.
Also, I'd like to see that anything at all which new-distutils
(whatever it be called) might need the old python.eclass for be
integrated into new-distutils (probably via new-python).
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBnGKkACgkQ2ugaI38ACPCUGQD/f2tf7bjyxkq52In7OrH+nDSL
nWLUWc9btwRm3Uuyd3AA/3tFI8uOiqpAVS7Ze4ScCt1UHi7LdvXgYGZRxPbJUbvS
=4o7s
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/29/2012 05:50 PM, Ian Stakenvicius wrote:
 On 29/09/12 11:45 AM, hasufell wrote:
 On 09/29/2012 05:37 PM, Ian Stakenvicius wrote:
 
 There isn't so much a problem with the current 
 python-distutils-ng eclass but rather it's to expand it to a
 more comprehensive replacement for both distutils and python
 eclasses. In order to do that efficiently, most of the core
 functionality should be moved so that the new distutils is more
 like a wrapper to the new python.
 
 This could certainly be done by patching the existing eclass,
 but mgorny wants to use new eclass names instead of keeping the
  current one.  Hence the rename.  I think that's about it..
 
 
 In that case we are missing 95% of the features of
 python.eclass.
 
 
 Aha, but do we really -need- 95% of the features?

Yeah, maybe not.

But that should be discussed beforehand imo. So that we really design
this eclass together. Otherwise I fear we will end up getting a 4th
implementation...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQZxmzAAoJEFpvPKfnPDWzi2AIAKQjjlbuf8K3TUFGmXPldTi4
sQJhwZjo4sngQF1zql4K2RJHnx2R6qsr/YteZ/4ek2yTg356oqkMjAyk5BV5Dpv8
shJugkgvAd3iZWVOUqQEMjxl+Rd3wRmgAw5oC+EEXrck6vOOgQbla/RdLwYFstkP
5Pmp+0hnksRcAnGhOiw7W0JLBJzuhPjoeUGdXVVVwuaPIzlgis0Jv8fSMeP4jxpT
vM5EOuvrwpM+gJzkpH0ABCdVHMyigufXCKED11JOrRTUA1fgT2XoWBMCblBoMXtH
e6WzUT5NojLlHn4E3psqy3kA4bqzRdMm6u3Iw4bPLFnl0vUaCGYqVfvL1OYkTU4=
=gbNx
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-29 Thread Ciaran McCreesh

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 29 Sep 2012 17:45:07 +0200
hasufell hasuf...@gentoo.org wrote:
 In that case we are missing 95% of the features of python.eclass.

You say that like it's a bad thing...

Seriously, most of the problem with python.eclass (and several other
problematic eclasses) is that it tries to do far too much all in one
place. More smaller eclasses is a good thing.

- -- 
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBnGacACgkQ96zL6DUtXhFFCgCfXr4BzUaN7L/WaAtYV//JOkjW
ES4AoNQU0/PwOBdzBTgspOt45V/2FDxG
=fvDp
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

On Sat, 29 Sep 2012 15:49:32 +0200
hasufell hasuf...@gentoo.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 09/29/2012 12:49 PM, Michał Górny wrote:
  On Sat, 29 Sep 2012 11:20:31 +0100 Markos Chandras
  hwoar...@gentoo.org wrote:
  
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
  
  On 09/29/2012 09:53 AM, Micha? Górny wrote:
  Hello,
  
  Instead of the floating patches and p-d-ng modifications I sent
   earlier, here are the two complete (so far, well, initial :P) 
  eclasses for review.
  
  They are designed as 'mostly' drop-in python-distutils-ng 
  replacement.
  
  Hi,
  
  Are you saying that you are going to remove the
  python-distutils-ng eclass in favour of the new eclasses? I don't
  quite understand the reasons to be honest.
  
  The reason is simple -- I can't fix it without changing the API. 
  Changing the API on a live eclass is confusing, and considering
  that it is not used by many packages, it's easier to lastrite it.
  
  Also, this fixes the name not to have any '-ng' nor '-ds9'.
  
 
 What are the reasons to change the API in the first place? There has
 to be a good reason, cause this will involve yet another migration of
 many ebuilds. I don't see any bugreports.

I have pointed out what changes to the API are _necessary_ to introduce
a good eclass on gentoo-python@.

Otherwise, the eclass would have to have at least two almost identical
functions doing the same thing, one universal and one for specific case
where specific parameters are passed (and not used in a single ebuild).

 I fear this will cause more confusion, i.e. some ebuilds using the old
 distutils, some using python-distutils-ng and some using distutils-r1
 resulting in weird tree behavior.

[example needed]

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

On Sat, 29 Sep 2012 16:37:15 +0200
Dirkjan Ochtman d...@gentoo.org wrote:

 On Sat, Sep 29, 2012 at 4:26 PM, hasufell hasuf...@gentoo.org wrote:
  That still does not explain the reasons why this work was initiated.
 
  If there is any way to fix the current eclass, that should be preferred.
 
 I tend to agree. Michał, let me first say I value the time you have
 invested to make the eclasses better. However, at this point I have a
 strong feeling that we have more people willing to write code to fix
 things than we have people building consensus on what
 features/policies/mechanisms we need to make it easy to write
 high-quality ebuilds for Python/distutils. I would prefer discussions
 on problems that the current ebuilds have and discussions on how to
 solve them, not at the code level, but that the mechanism level.

The main issue: noone wants to even touch python.eclass or anything
nearby.

The second issue: python-distutils-ng isn't good enough. It has too
many things hard-wired. I think I have already pointed enough problems
with it. Not that many people cared to respond.

It's sad that people don't care to respond when you point the issues
out but then complain when you do something to fix them.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

On Sat, 29 Sep 2012 17:45:07 +0200
hasufell hasuf...@gentoo.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 09/29/2012 05:37 PM, Ian Stakenvicius wrote:
  
  There isn't so much a problem with the current python-distutils-ng 
  eclass but rather it's to expand it to a more comprehensive 
  replacement for both distutils and python eclasses.  In order to
  do that efficiently, most of the core functionality should be moved
  so that the new distutils is more like a wrapper to the new
  python.
  
  This could certainly be done by patching the existing eclass, but 
  mgorny wants to use new eclass names instead of keeping the
  current one.  Hence the rename.  I think that's about it..
  
 
 In that case we are missing 95% of the features of python.eclass.

Please list the features. Preferably, order them by usefulness, with
exact use cases.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-29 Thread Pacho Ramos

El sáb, 29-09-2012 a las 20:40 +0200, Michał Górny escribió:
 On Sat, 29 Sep 2012 17:45:07 +0200
 hasufell hasuf...@gentoo.org wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  On 09/29/2012 05:37 PM, Ian Stakenvicius wrote:
   
   There isn't so much a problem with the current python-distutils-ng 
   eclass but rather it's to expand it to a more comprehensive 
   replacement for both distutils and python eclasses.  In order to
   do that efficiently, most of the core functionality should be moved
   so that the new distutils is more like a wrapper to the new
   python.
   
   This could certainly be done by patching the existing eclass, but 
   mgorny wants to use new eclass names instead of keeping the
   current one.  Hence the rename.  I think that's about it..
   
  
  In that case we are missing 95% of the features of python.eclass.
 
 Please list the features. Preferably, order them by usefulness, with
 exact use cases.
 

Personally, I usually run:
- python_clean_py-compile_files - Clean py-compile files to disable
byte-compilation allowing us to drop all various ways of doing this that
were living in the tree some time ago.
- python_convert_shebangs - but, I guess this is handled in a different
way in your eclass, no? :/



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

2012-09-29 Thread Luca Barbato

On 09/29/2012 12:45 PM, Michał Górny wrote:
 On Sat, 29 Sep 2012 12:00:18 +0200
 Tomáš Chvátal tomas.chva...@gmail.com wrote:
 
 2012/9/29 Michał Górny mgo...@gentoo.org:
 Hello,

 Instead of the floating patches and p-d-ng modifications I sent
 earlier, here are the two complete (so far, well, initial :P) eclasses
 for review.

 They are designed as 'mostly' drop-in python-distutils-ng replacement.

 Hi,

 the eclasses look pretty, so good job,
 just one question tho, would it be possible to use more
 debug-something calls so the log file would be populated automatically
 with whats going on (same like eg git-2 eclass)?
 
 Try now :P.
 
Looks even nicer, great!

lu

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass

On Sat, 29 Sep 2012 21:20:00 +0200
Pacho Ramos pa...@gentoo.org wrote:

 El sáb, 29-09-2012 a las 20:40 +0200, Michał Górny escribió:
  On Sat, 29 Sep 2012 17:45:07 +0200
  hasufell hasuf...@gentoo.org wrote:
  
   -BEGIN PGP SIGNED MESSAGE-
   Hash: SHA1
   
   On 09/29/2012 05:37 PM, Ian Stakenvicius wrote:

There isn't so much a problem with the current python-distutils-ng 
eclass but rather it's to expand it to a more comprehensive 
replacement for both distutils and python eclasses.  In order to
do that efficiently, most of the core functionality should be moved
so that the new distutils is more like a wrapper to the new
python.

This could certainly be done by patching the existing eclass, but 
mgorny wants to use new eclass names instead of keeping the
current one.  Hence the rename.  I think that's about it..

   
   In that case we are missing 95% of the features of python.eclass.
  
  Please list the features. Preferably, order them by usefulness, with
  exact use cases.
  
 
 Personally, I usually run:
 - python_clean_py-compile_files - Clean py-compile files to disable
 byte-compilation allowing us to drop all various ways of doing this that
 were living in the tree some time ago.

Hmm, what's the problem with compiling them? Do you mean some case when
the results of the compilation are different from the way done
by the eclass?

 - python_convert_shebangs - but, I guess this is handled in a different
 way in your eclass, no? :/

Depends on what you need. To be honest, I haven't added any code for
custom script handling yet, just the usual distutils case.

A package which does not explicitly support multiple Python
implementations is a completely different things, needing more
discussion first and which actually may be handled through a separate
eclass if most code of python-r1 proves useless for it.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] Initial python-r1.eclass distutils-r1.eclass