public inbox for gentoo-python@lists.gentoo.org
 help / color / mirror / Atom feed
From: Maxim Koltsov <maksbotan@gentoo.org>
To: gentoo-python@lists.gentoo.org
Subject: [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass
Date: Sat, 26 May 2012 13:32:30 +0400	[thread overview]
Message-ID: <CAB_Kkxz_cD5zJO0ELbomO4g-bPjp0yED3E=s0RccziWLEZvvjg@mail.gmail.com> (raw)
In-Reply-To: <CAB_KkxwspDjWOpV7FSdwxD5MHS-qjtxrUQBiwbsc2yRhqXQntQ@mail.gmail.com>

Hi,
This can be another troll-thread or layman-thread, but still I think
this question must be raised once more.
I want to say that I personally don't want to use python-distutils-ng
in its current state and I know several active python ebuild writers
that are not Gentoo developers and they don't want to use it too.
First of all, how well is this eclass adapted to packages not using
distutils? Old eclass had set of convenient functions
(python_execute_function, python_generate_wrapper_scripts,
python_conver_shebangs). I see some functions like these ones in new
eclass, but can they serve as good replace and is their API public and
stable?
Then, we think that this ruby-ng style approach with PYTHON_TARGETS is
a bit uncomfortable for end users and developers. This is going to be
pain for all users if eclass gets used widely. Eclass allows developer
not to set PYTHON_COMPAT and populate it with all available values —
well, it's nice. But imagine that Python 3.3 arrives. All ebuilds
using new eclass will get new IUSE and therefore will be rebuilt
during emerge --update --newuse world. That's hardly sensible. It's
awful to rebuild packages which might be very 'heavy' just for
nothing.
On the other hand, if developers are forced to set PYTHON_COMPAT, this
will result in great delays in getting new python support to Gentoo.
You can say that ruby-ng has the same behavior and nobody complains.
But python is not ruby. Ruby 1.8 to 1.9 transitition was connected
with a lot of incompabilities, so one could not assume that ruby-1.8
package will work on 1.9. Python 3.2 to 3.3 transitition should be
harmless and almost all packages will require no changes. So some
implicit mechanism of doing this must be implemented.
So, new eclass has serious problems, old is bad too, not to say here
why, and we have no solution yet :)
But still discussion is needed, or we will end up accepting silently
bad decisions. Please speak up everyone who agrees with me and/or has
any suggestions.



       reply	other threads:[~2012-05-26  9:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAB_KkxwspDjWOpV7FSdwxD5MHS-qjtxrUQBiwbsc2yRhqXQntQ@mail.gmail.com>
2012-05-26  9:32 ` Maxim Koltsov [this message]
2012-05-26  9:53   ` [gentoo-python] python-distutils.eclass vs. python.eclass + distutils.eclass Dirkjan Ochtman
2012-05-26 13:01     ` Nikolaj Sjujskij
2012-05-26 13:07       ` Michał Górny
2012-05-26 13:09         ` Nikolaj Sjujskij
2012-05-26 18:28           ` Krzysztof Pawlik
2012-05-26 18:45             ` Maxim Koltsov
2012-05-26 19:07               ` Michał Górny
2012-06-01 10:36             ` Nikolaj Sjujskij
2012-05-26 13:33       ` Mike Gilbert
2012-06-01 12:42         ` Nikolaj Sjujskij
2012-05-26  9:53   ` Michał Górny
2012-05-26  9:55     ` Dirkjan Ochtman
2012-05-26 10:06       ` Michał Górny
2012-05-26 18:31         ` Krzysztof Pawlik
2012-05-26 23:18           ` Mike Gilbert

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='CAB_Kkxz_cD5zJO0ELbomO4g-bPjp0yED3E=s0RccziWLEZvvjg@mail.gmail.com' \
    --to=maksbotan@gentoo.org \
    --cc=gentoo-python@lists.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