public inbox for gentoo-python@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev-announce@lists.gentoo.org
Cc: gentoo-python@lists.gentoo.org
Subject: [gentoo-python] distutils-r1: parallel run support out, guaranteed cwd in sub-phase in
Date: Thu, 11 Dec 2014 20:04:40 +0100	[thread overview]
Message-ID: <20141211200440.5cb07325@pomiot.lan> (raw)

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

Hello, developers.

The distutils-r1 eclass (and the python-r1 eclass used it to implement
it) have seen a few minor changes recently. Hopefully, they will make
Python ebuild writing easier and more predictable.


Firstly, we have completely removed the parallel run support. This
means that in particular:

a. all of python_* phases are always run in series.

b. python_parallel_foreach_impl() is deprecated, and works as alias to
python_foreach_impl(). You can replace it with the latter at any time.

c. DISTUTILS_JOBS and DISTUTILS_NO_PARALLEL_BUILD no longer have any
meaning. The former may be removed from make.conf, the latter from
ebuilds,

d. All non-local variables set within sub-phase functions will be
passed through to the next sub-phase executions. Please ensure to use
'local' whenever necessary ;).

The rationale can be found at [1]. Long story short, the parallel runs
gave real gains only in corner cases, while some more corner cases
required them disabled. They triggered a lot of bugs in build systems
which imposed a serious amount of work on our developers, and often
confused our users.


Secondly, we have added a clear guarantee that the working directory
is restored after each sub-phase function invocation returns. In other
words, you are free to 'cd' anywhere you want in a sub-phase function,
and you can safely assume that the next Python implementation will
start with the same initial directory, and that that directory will be
restored once distutils-r1_src_* leaves.

This is pretty much a bugfix for the first change. Since parallel runs
caused sub-phase functions to be run in subshells, the directory
changes within didn't affect the further calls. Additionally,
DISTUTILS_IN_SOURCE_BUILD restored working directory on leave. Since we
no longer have subshells and bugs started appearing, we decided to
remove these implicit conditionals and just preserve working directory
unconditionally.


Hope these changes make the eclasses a bit easier on you. We still have
over 250 distutils ebuilds to update [2]! Have fun.


[1]:http://thread.gmane.org/gmane.linux.gentoo.python/641
[2]:http://dev.gentoo.org/~mgorny/python-r1/conversion.xhtml

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

                 reply	other threads:[~2014-12-11 19:04 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20141211200440.5cb07325@pomiot.lan \
    --to=mgorny@gentoo.org \
    --cc=gentoo-dev-announce@lists.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