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-29-2011, 04:34 AM
Michał Górny
 
Default The Python problem

On Tue, 28 Jun 2011 20:03:34 -0430
"Jesus Rivero (Neurogeek)" <neurogeek@gentoo.org> wrote:

> On Mon, Jun 27, 2011 at 7:58 AM, Dirkjan Ochtman <djc@gentoo.org>
> wrote:
> > Hi guys,
> [...]
> > 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 start by agreeing with the complexity of the Python eclass. And
> a heavy change right now, is going to be painful to say the least
> because a great deal of packages have been adapted to work the way the
> eclass works right now.
>
> [...]
>
> As I said it already, we could start doing things simpler in the
> current python.eclass and maybe that would attract some devs to help
> out with it, as they find it more comfortable to work with.

I think it would be better to simply start from scratch with
a clean python-2.eclass. Instead of adding new features and another lot
of conditionals for EAPI=4, just make that code a part of new eclass.

And remember, the more complex code is, the more painful it becomes for
things like metadata generation.

--
Best regards,
Michał Górny
 
Old 06-29-2011, 07:18 AM
"Andreas K. Huettel"
 
Default The Python problem

Am Mittwoch, 29. Juni 2011, 06:34:52 schrieb Michał Górny:
>
> > As I said it already, we could start doing things simpler in the
> > current python.eclass and maybe that would attract some devs to help
> > out with it, as they find it more comfortable to work with.
>
> I think it would be better to simply start from scratch with
> a clean python-2.eclass. Instead of adding new features and another lot
> of conditionals for EAPI=4, just make that code a part of new eclass.
>

Ack. The cleanest way would definitely be to start from scratch, and provide a
looooong transition period. Please please make things similar compared to the
other language eclasses, though...

--
Andreas K. Huettel (dilfridge)
Gentoo Linux developer
kde, sci, arm, tex
 
Old 06-29-2011, 10:16 AM
Pacho Ramos
 
Default The Python problem

El mié, 29-06-2011 a las 09:18 +0200, Andreas K. Huettel escribió:
> Am Mittwoch, 29. Juni 2011, 06:34:52 schrieb Michał Górny:
> >
> > > As I said it already, we could start doing things simpler in the
> > > current python.eclass and maybe that would attract some devs to help
> > > out with it, as they find it more comfortable to work with.
> >
> > I think it would be better to simply start from scratch with
> > a clean python-2.eclass. Instead of adding new features and another lot
> > of conditionals for EAPI=4, just make that code a part of new eclass.
> >
>
> Ack. The cleanest way would definitely be to start from scratch, and provide a
> looooong transition period. Please please make things similar compared to the
> other language eclasses, though...
>

Arfrever added support for eapi4 in python-overlay, maybe trying to move
it to the tree would be faster :-/
 
Old 06-29-2011, 12:19 PM
Arfrever Frehtes Taifersar Arahesis
 
Default The Python problem

2011-06-29 02:33:34 Jesus Rivero (Neurogeek) napisał(a):
> With python-updater, well, some time ago Ali Polatel implemented some
> approaches to get rid of python-updater, by exporting some variable in
> ebuilds that needed to be rebuilt when new python versions were
> installed. I dont recall what happened with that, but we could think
> of some ways to finally get rid of python-updater.

He added python_need_rebuild() function, which sets PYTHON_NEED_REBUILD variable, which is
checked by python-updater, so that python-updater can avoid checking CONTENTS files in VDB
and calling scanelf on all installed files.

--
Arfrever Frehtes Taifersar Arahesis
 
Old 06-29-2011, 12:19 PM
Arfrever Frehtes Taifersar Arahesis
 
Default The Python problem

2011-06-29 02:33:34 Jesus Rivero (Neurogeek) napisał(a):
> With python-updater, well, some time ago Ali Polatel implemented some
> approaches to get rid of python-updater, by exporting some variable in
> ebuilds that needed to be rebuilt when new python versions were
> installed. I dont recall what happened with that, but we could think
> of some ways to finally get rid of python-updater.

He added python_need_rebuild() function, which sets PYTHON_NEED_REBUILD variable, which is
checked by python-updater, so that python-updater can avoid checking CONTENTS files in VDB
and calling scanelf on all installed files.

--
Arfrever Frehtes Taifersar Arahesis
 
Old 06-29-2011, 12:43 PM
Arfrever Frehtes Taifersar Arahesis
 
Default The Python problem

2011-06-27 22:57:05 Thomas Sachau napisał(a):
> Dirkjan Ochtman wrote:
> > 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:
> >> 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.
>
> You wont be able to prevent this with a general solution, only with some specialized solution inside
> the build, if you really want and need that.
> Currently, if you want python bindings for three different python environments, you will have to
> build everything for all three python environments, even if you only need a subset.

Building everything for all Python ABIs is not required in case of majority of packages, which
optionally install Python bindings. Makefiles of many packages (including dev-vcs/subversion)
provide separate targets for building/installation of core libraries and various bindings.

Example:

src_compile() {
emake || die

if use python; then
python_copy_sources bindings/python
build_python_bindings() {
emake
PYTHON_INCLUDES="$(python_get_includedir)"
PYTHON_SITE_PACKAGES="$(python_get_sitedir)"
python_bindings
}
python_execute_function -s --source-dir bindings/python build_python_bindings
fi
}


--
Arfrever Frehtes Taifersar Arahesis
 

Thread Tools




All times are GMT. The time now is 05:01 PM.

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