public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: pacho@gentoo.org
Subject: Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
Date: Sat, 29 Sep 2012 22:34:07 +0200	[thread overview]
Message-ID: <20120929223407.0940bf4f@pomiocik.lan> (raw)
In-Reply-To: <1348946400.2200.6.camel@belkin4>

[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

  reply	other threads:[~2012-09-29 20:35 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-29  8:53 [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass Michał Górny
2012-09-29 10:00 ` Tomáš Chvátal
2012-09-29 10:23   ` Michał Górny
2012-09-29 10:45   ` Michał Górny
2012-09-29 19:34     ` Luca Barbato
2012-09-29 10:20 ` Markos Chandras
2012-09-29 10:49   ` Michał Górny
2012-09-29 13:49     ` hasufell
2012-09-29 14:19       ` Ian Stakenvicius
2012-09-29 14:26         ` hasufell
2012-09-29 14:37           ` Dirkjan Ochtman
2012-09-29 18:39             ` Michał Górny
2012-09-29 20:48               ` hasufell
2012-09-30 14:01                 ` Michał Górny
2012-09-29 15:37           ` Ian Stakenvicius
2012-09-29 15:45             ` hasufell
2012-09-29 15:50               ` Ian Stakenvicius
2012-09-29 15:54                 ` hasufell
2012-09-29 15:54               ` Ciaran McCreesh
2012-09-29 18:40               ` Michał Górny
2012-09-29 19:20                 ` Pacho Ramos
2012-09-29 20:34                   ` Michał Górny [this message]
2012-09-30  8:31                     ` Pacho Ramos
2012-09-30  8:58                       ` Fabian Groffen
2012-09-30  9:47                         ` Pacho Ramos
2012-09-30 13:28                         ` Michał Górny
2012-09-30 13:47                           ` Fabian Groffen
2012-09-30 13:57                         ` Michał Górny
2012-09-30 14:12                           ` Fabian Groffen
2012-09-30 18:15                             ` Zac Medico
2012-09-30 21:47                         ` Brian Harring
2012-10-01  6:36                           ` Fabian Groffen
2012-10-01  7:19                             ` Brian Harring
2012-10-01 15:17                             ` Marien Zwart
2012-10-01 15:44                               ` Fabian Groffen
2012-09-29 15:47             ` hasufell
2012-09-29 18:35       ` Michał Górny
2012-09-30  5:09   ` Ben de Groot
2012-10-05 12:42 ` Michał Górny
2012-10-25 16:41 ` hasufell
2012-10-25 17:10   ` Ian Stakenvicius
2012-10-25 17:43   ` Michał Górny
2012-10-25 18:55     ` hasufell
2012-10-25 20:13       ` Michał Górny
2012-10-26 18:28         ` hasufell
2012-10-25 20:37       ` Michał Górny
2012-10-25 19:19   ` hasufell
2012-10-25 20:40     ` Michał Górny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120929223407.0940bf4f@pomiocik.lan \
    --to=mgorny@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=pacho@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox