FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-29-2012, 07:34 PM
Luca Barbato
 
Default Initial python-r1.eclass & distutils-r1.eclass

On 09/29/2012 12:45 PM, Michał Górny wrote:
> On Sat, 29 Sep 2012 12:00:18 +0200
> Tomáš Chvátal <tomas.chvatal@gmail.com> wrote:
>
>> 2012/9/29 Michał Górny <mgorny@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
 
Old 09-29-2012, 08:34 PM
Michał Górny
 
Default Initial python-r1.eclass & distutils-r1.eclass

On Sat, 29 Sep 2012 21:20:00 +0200
Pacho Ramos <pacho@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 <hasufell@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
 
Old 09-29-2012, 08:48 PM
hasufell
 
Default Initial python-r1.eclass & distutils-r1.eclass

-----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 <djc@gentoo.org>
> wrote:
>
>> On Sat, Sep 29, 2012 at 4:26 PM, hasufell <hasufell@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.

> [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.

> 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?
How can I convert shebangs consistently and recursively?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQZ16AAAoJEFpvPKfnPDWzzMgH/0dGzePj8eSrZ3OZDzwMYE3B
Vx8BiD2Vd+OnGyq2w0infJpN8lDlGu+8yxGwWervZJ7tIxqabh QokI03tBSyLRgt
em5R+AgSiR6GSiIRfMNoFYj+5zR8vz4gHtCzrI47O8W6R6e3fR j3JKShY7+T4Djz
vBMyD4ZuxLg0CnvJ05rrc41CEvmAY/aWysS5WNoevdx8Jf8exaVtfp6TXGu/q+JV
7py4gFA5wXmb7UCv9Tcw0IxiglVAfEJRzvRh68TComBKWuUw0Y hGd/x2VxaLZ0dr
ghCt4XBjyi5g4q1rcDedEPowth1Q/9M6VpP6fT5ZTPVIs5r49G9vMcRymppWetM=
=5M+2
-----END PGP SIGNATURE-----
 
Old 09-30-2012, 05:09 AM
Ben de Groot
 
Default Initial python-r1.eclass & distutils-r1.eclass

On 29 September 2012 18:20, Markos Chandras <hwoarang@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 09/29/2012 09:53 AM, Micha? Grny 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 current python.eclass is too horribly complicated, and should go
the way of the dodo ASAP; while on the other hand python-distutils-ng
is too limited (e.g. for non-distutils multiple-implementation python
needing packages) and oddly named.

I fully support this attempt to improve the current situation, and as
I understand so does most of our python team.

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
 
Old 09-30-2012, 08:31 AM
Pacho Ramos
 
Default Initial python-r1.eclass & distutils-r1.eclass

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 <pacho@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 <hasufell@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
 
Old 09-30-2012, 08:58 AM
Fabian Groffen
 
Default Initial python-r1.eclass & distutils-r1.eclass

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
 
Old 09-30-2012, 09:47 AM
Pacho Ramos
 
Default Initial python-r1.eclass & distutils-r1.eclass

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
 
Old 09-30-2012, 01:28 PM
Michał Górny
 
Default Initial python-r1.eclass & distutils-r1.eclass

On Sun, 30 Sep 2012 10:58:06 +0200
Fabian Groffen <grobian@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
 
Old 09-30-2012, 01:47 PM
Fabian Groffen
 
Default Initial python-r1.eclass & distutils-r1.eclass

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
 
Old 09-30-2012, 01:57 PM
Michał Górny
 
Default Initial python-r1.eclass & distutils-r1.eclass

On Sun, 30 Sep 2012 10:58:06 +0200
Fabian Groffen <grobian@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
 

Thread Tools




All times are GMT. The time now is 05:09 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org