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 06-27-2011, 12:56 PM
"Pascal J. Bourguignon"
 
Default The Python problem

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
 
Old 06-27-2011, 12:57 PM
"Pascal J. Bourguignon"
 
Default The Python problem

Dirkjan Ochtman <djc@gentoo.org> writes:

> I guess by now pretty much everyone knows that the python eclass is
> rather complex, and that this poses some problems. This has also been
> an important cause for the disagreements between Arfrever and some of
> the other developers. Since it appears that Arfrever won't be
> committing much code to gentoo-x86 in the near future, I'm trying to
> figure out where we should go with the python.eclass. This email is an
> attempt at figuring that out, plus eliciting ideas to come up with a
> general framework that will also solve this for ruby and other similar
> runtimes (while supporting some of the features that the current
> python eclass has, but that ruby-ng doesn't have).
>
> So I know a bunch of people have already looked at it, and I'd like to
> know: what do you find better about the Ruby approach compared to the
> Python approach? Is it just the size of python.eclass, or are there a
> number of other issues?

Let's skip the Ruby step, and go directly to Common Lisp!

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
 
Old 06-27-2011, 01:08 PM
Fabian Groffen
 
Default The Python problem

On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote:
> So I know a bunch of people have already looked at it, and I'd like to
> know: what do you find better about the Ruby approach compared to the
> Python approach? Is it just the size of python.eclass, or are there a
> number of other issues?

Part of the eclass problem is IMO coding style. Change it to use
normally-sized variable names, and to respect 80-columns width, and it
already becomes much more consumable.

The whole comparison of Python vs Ruby vs Java and perhaps the outlook
to Perl is kind of hard. What the python eclass accomplishes is very
neat. What probably started as a way to be able to have both python 2.x
and 3.x installed side by side (because the latter is not really
compatible with the former) got IMO out of hand by supporting any python
version to coexist with another. I guess many people developing with
Python actually love this feature, and in itself, I believe it has use
that cannot be ignored any more now. The way in which this feature was
implemented -- sometimes it more felt as pushed through the throat -- is
more of the rebelious kind than the smooth path for ebuild developers.

It would be nice when a similar technique could be implemented only
once, in a consistent way. In a way, multilib-portage can be considered
equal to one of the objectives of the python (and ruby) eclass:
multiple times compiling and installing for different ABIs.

All in all, I don't fancy a rewrite from scratch, since it all works
at the moment, and doing so takes another large bit of work. Instead,
aligning the work with others to create a similar approach in ebuilds
(for ebuild developers) would be favourable to me. And perhaps that
should mean that variables which contain versions with some syntax that
specify ranges and more should just go, to be replaced by something
which is much less powerful in expressiveness, but much easier to
understand in the general picture, such as the USE-flags from the ruby
eclass.

Just my €0.02


--
Fabian Groffen
Gentoo on a different level
 
Old 06-27-2011, 01:43 PM
Dirkjan Ochtman
 
Default The Python problem

On Mon, Jun 27, 2011 at 15:08, Fabian Groffen <grobian@gentoo.org> wrote:
> On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote:
>> So I know a bunch of people have already looked at it, and I'd like to
>> know: what do you find better about the Ruby approach compared to the
>> Python approach? Is it just the size of python.eclass, or are there a
>> number of other issues?
>
> Part of the eclass problem is IMO coding style. *Change it to use
> normally-sized variable names, and to respect 80-columns width, and it
> already becomes much more consumable.

That seems like the somewhat more straightforward part.

> The whole comparison of Python vs Ruby vs Java and perhaps the outlook
> to Perl is kind of hard. *What the python eclass accomplishes is very
> neat. *What probably started as a way to be able to have both python 2.x
> and 3.x installed side by side (because the latter is not really
> compatible with the former) got IMO out of hand by supporting any python
> version to coexist with another. *I guess many people developing with
> Python actually love this feature, and in itself, I believe it has use
> that cannot be ignored any more now. *The way in which this feature was
> implemented -- sometimes it more felt as pushed through the throat -- is
> more of the rebelious kind than the smooth path for ebuild developers.

Right. I think the ability to have python packages simultaneously
installed in python2.6, python2.7 and pypy1.5, for example, is pretty
cool to have. And going from USE to RESTRICT (Ruby vs. Python, right
now) is probably more sensible in the Python ecosystem (i.e. where
something that runs on 2.6 is likely to also run on 2.7).

> It would be nice when a similar technique could be implemented only
> once, in a consistent way. *In a way, multilib-portage can be considered
> equal to one of the objectives of the python (and ruby) eclass:
> multiple times compiling and installing for different ABIs.

Yeah, but it'd be nice not to have to compile subversion three times
just because we want the python bindings installed in three different
Python environments.

> All in all, I don't fancy a rewrite from scratch, since it all works
> at the moment, and doing so takes another large bit of work. *Instead,
> aligning the work with others to create a similar approach in ebuilds
> (for ebuild developers) would be favourable to me. *And perhaps that
> should mean that variables which contain versions with some syntax that
> specify ranges and more should just go, to be replaced by something
> which is much less powerful in expressiveness, but much easier to
> understand in the general picture, such as the USE-flags from the ruby
> eclass.

That sounds very similar to what I think would be best.

Cheers,

Dirkjan
 
Old 06-27-2011, 03:53 PM
Petteri Räty
 
Default The Python problem

On 27.06.2011 15:28, Dirkjan Ochtman wrote:
>
> So I know a bunch of people have already looked at it, and I'd like to
> know: what do you find better about the Ruby approach compared to the
> Python approach? Is it just the size of python.eclass, or are there a
> number of other issues?
>

I like the ruby approach for the reason that it doesn't require users to
run update scripts like python-updater.

Regards,
Petteri
 
Old 06-27-2011, 04:00 PM
Dirkjan Ochtman
 
Default The Python problem

On Mon, Jun 27, 2011 at 17:53, Petteri Räty <betelgeuse@gentoo.org> wrote:
> I like the ruby approach for the reason that it doesn't require users to
> run update scripts like python-updater.

Sure, but if that means the developers now have to bump every package
in the tree when a new version of Python comes out, I'm not sure
that's the best trade-off.

Cheers,

Dirkjan
 
Old 06-27-2011, 06:23 PM
Benedikt Böhm
 
Default The Python problem

On Mon, Jun 27, 2011 at 2:28 PM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> So I know a bunch of people have already looked at it, and I'd like to
> know: what do you find better about the Ruby approach compared to the
> Python approach? Is it just the size of python.eclass, or are there a
> number of other issues?

the way python applications are built currently renders all binary
packages useless, since portage does not know which version of python
it was built against. the explicit selection with RUBY_TARGETS or
PHP_TARGETS solves this problem at the small cost of commiting new
values to these variables from time to time.
 
Old 06-27-2011, 07:31 PM
Michał Górny
 
Default The Python problem

On Mon, 27 Jun 2011 14:28:34 +0200
Dirkjan Ochtman <djc@gentoo.org> wrote:

> So I know a bunch of people have already looked at it, and I'd like to
> know: what do you find better about the Ruby approach compared to the
> Python approach? Is it just the size of python.eclass, or are there a
> number of other issues?

Working targets. USE_PYTHON is junk. What python.eclass does now with
ABIs is a PITA, and requires manually providing a lot of redudant
information (namely, RESTRICT_PYTHON_ABIS).

Right now, each ebuild has to provide the same information in
PYTHON_DEPEND and RESTRICT_PYTHON_ABIS. Moreover, if an ebuild
supports, say, py3 and its dependency doesn't, the ebuild has to
restrict py3 too.

I'd like to see that fixed somehow. I'd like to set a single supported
Python version information in an ebuild, and let the dependency
resolver handle everything else.

--
Best regards,
Michał Górny
 
Old 06-27-2011, 08:46 PM
Petteri Räty
 
Default The Python problem

On 27.06.2011 19:00, Dirkjan Ochtman wrote:
> On Mon, Jun 27, 2011 at 17:53, Petteri Räty <betelgeuse@gentoo.org> wrote:
>> I like the ruby approach for the reason that it doesn't require users to
>> run update scripts like python-updater.
>
> Sure, but if that means the developers now have to bump every package
> in the tree when a new version of Python comes out, I'm not sure
> that's the best trade-off.
>

And why can't this be handled by the eclass? If the ebuild is able to
specify it supports >=3.0 meaning it's expected that future versions
work then the eclass can make the new values available through IUSE when
new python versions are out and ebuilds don't require any changes.

Regards,
Petteri
 
Old 06-27-2011, 08:49 PM
Mike Frysinger
 
Default The Python problem

On Monday, June 27, 2011 09:43:05 Dirkjan Ochtman wrote:
> On Mon, Jun 27, 2011 at 15:08, Fabian Groffen wrote:
> > It would be nice when a similar technique could be implemented only
> > once, in a consistent way. In a way, multilib-portage can be considered
> > equal to one of the objectives of the python (and ruby) eclass:
> > multiple times compiling and installing for different ABIs.
>
> Yeah, but it'd be nice not to have to compile subversion three times
> just because we want the python bindings installed in three different
> Python environments.

it'd be nice to not build glibc multiple times for diff multilibs, but it
simply isnt possible. either you want multilib support (or in this case
multi-python version support), or you dont. if this feature is something like
(and it sounds like it is), then this is simply something that is accepted.

if you dont want multiple builds on your system, then dont install multiple
versions of python.
-mike
 

Thread Tools




All times are GMT. The time now is 02:51 AM.

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