unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / Atom feed
* Questions regarding Python packaging
@ 2020-11-08 14:27 Tanguy Le Carrour
  2020-11-08 17:05 ` Leo Famulari
                   ` (3 more replies)
  0 siblings, 4 replies; 23+ messages in thread
From: Tanguy Le Carrour @ 2020-11-08 14:27 UTC (permalink / raw)
  To: Guix

Hi Guix!

I have some general questions regarding Python packaging, that are not
directly related to the "poetry build system" I'm currently working on.

I've just learned, by accident (working on `python-keyring` [1]), that
`python setup.py install` was somehow deprecated in favor of tools like
`pep517` or `build`.

So, I've tried packaging `python-keyring` with those two…

`pep517` keeps on trying to download dependencies, which won't work.

`build` crashes with "ZIP does not support timestamps before 1980",
which, I guess is related to the fact that everything in the store is
timestamped to January 1st 1970.

Does anyone have a opinion on Python packaging and how it should be done?
Any idea how I can circumvent the timestamps problem? Is this fish too
big for me?!

Any help or advice welcome! Thanks!

-- 
Tanguy

[1]: https://github.com/jaraco/keyring/issues/469
     Keyring package version is set to 0.0.0, this might be related to
     the fact that, upstream, they build it with `python -m pep517.build .`,
     not with `python setup.py install`… but it could also not be
     related at all! But in order to be sure, I have to try!



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2020-11-08 14:27 Questions regarding Python packaging Tanguy Le Carrour
@ 2020-11-08 17:05 ` Leo Famulari
  2020-11-10  8:35   ` Tanguy Le Carrour
  2020-11-08 20:43 ` Michael Rohleder
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 23+ messages in thread
From: Leo Famulari @ 2020-11-08 17:05 UTC (permalink / raw)
  To: Tanguy Le Carrour; +Cc: Guix

On Sun, Nov 08, 2020 at 03:27:17PM +0100, Tanguy Le Carrour wrote:
> `pep517` keeps on trying to download dependencies, which won't work.

That usually means that the software is missing some dependencies. If
you think they should be available in the build environment,
double-check that they are, and then look into how the software is
looking for them.

Also, Python software seems to change a lot, and quickly — make sure you
are using the correct version of all the dependencies.

> `build` crashes with "ZIP does not support timestamps before 1980",
> which, I guess is related to the fact that everything in the store is
> timestamped to January 1st 1970.

Are you using the python-build-system? It should handle this problem
with its 'ensure-no-mtimes-pre-1980' phase.

> Does anyone have a opinion on Python packaging and how it should be done?
> Any idea how I can circumvent the timestamps problem? Is this fish too
> big for me?!

In general, Python packaging is on the easy side but, when it gets
complicated (e.g. due to unusual design of the upstream build scripts),
it can be really complicated.

> Any help or advice welcome! Thanks!

If will help if you share your package definition.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2020-11-08 14:27 Questions regarding Python packaging Tanguy Le Carrour
  2020-11-08 17:05 ` Leo Famulari
@ 2020-11-08 20:43 ` Michael Rohleder
  2020-11-10  8:30   ` Tanguy Le Carrour
  2020-11-09 16:54 ` Hartmut Goebel
  2021-01-05 10:25 ` Lars-Dominik Braun
  3 siblings, 1 reply; 23+ messages in thread
From: Michael Rohleder @ 2020-11-08 20:43 UTC (permalink / raw)
  To: Tanguy Le Carrour; +Cc: Guix

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

Hello Tanguy,

Tanguy Le Carrour <tanguy@bioneland.org> writes:
> I've just learned, by accident (working on `python-keyring` [1]), that
> `python setup.py install` was somehow deprecated in favor of tools like
> `pep517` or `build`.
>
> So, I've tried packaging `python-keyring` with those two…

apropos python-keyring:

I also tried to update that package (in order to package "pantalaimon"
which needs this) [1]
The problem with this thing is, it wants to install an egginfo with
version 0.0.0, no matter if build with setup.py or poetry [2]

I tried debugging^Whacking this a while (eg. updateing setuptools, as
suggested in the ticket), but couldn't make it work.
If you find a solution, I'd be interested ;)


Footnotes:
[1] https://rohleder.de/gitweb/?p=guix.git;a=blob;f=mroh/guix/packages/python.scm;h=0c847795375ce08ca878727f15fd1a1b156df6f7;hb=HEAD#l533
[2] https://github.com/jaraco/keyring/issues/469

-- 
There are no winners in life, only survivors.

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2020-11-08 14:27 Questions regarding Python packaging Tanguy Le Carrour
  2020-11-08 17:05 ` Leo Famulari
  2020-11-08 20:43 ` Michael Rohleder
@ 2020-11-09 16:54 ` Hartmut Goebel
  2020-11-10  8:47   ` Tanguy Le Carrour
  2021-01-05 10:25 ` Lars-Dominik Braun
  3 siblings, 1 reply; 23+ messages in thread
From: Hartmut Goebel @ 2020-11-09 16:54 UTC (permalink / raw)
  To: guix-devel

Hi,

seems like another messages of mine, regarding the first thread  about a 
poetry build system, did not make it to the list.

Am 08.11.20 um 15:27 schrieb Tanguy Le Carrour:
> I've just learned, by accident (working on `python-keyring` [1]), that
> `python setup.py install` was somehow deprecated

This statement is not exactly true - well, depending on interpretation 
of "somehow". I've not set seen an official deprecation.

It's true that users are encouraged to use pip for installing packages. 
But the official Python Packaging Tutorial [1] is still based on 
setuptools (not even recommending a setup.cfg file). Thus setuptools 
will be around for quite some more time, as will "python setup.py install".

In the future Python world, any build-tool can be specified in 
"pyproject.toml". User will then call "pip install", and pip will 
(AFAIU) call a Python function (aka entry-point) specified in that file. 
(If this file does not exist, setuptools are assumed). For our 
python-build-system, we would use "pip wheel" (for phase build) and "pip 
install" (for phase install).

So, if we switch to "pip wheel" and "pip install", different python 
build systems could share a common base, just redefining some 
dependencies (setuptools, poetry, build, ...) and some tool-dependent 
flags. Is this the direction you are working towards?

[1] https://packaging.python.org/tutorials/packaging-projects/


> in favor of tools like`pep517` or `build`.

Thanks for point to these, both are new to me.

"build" sounds interesting, esp. for guix: "It is a simple build tool 
and does not perform any dependency management." This would help us 
spliting dependency management and build phase. Anyhow, it's quite new 
(half an year old) and implements a PEP 517 package builder - and PEP 
517 (defining the build system in pyproject.toml) is not yet adopted widely.

"pep517" seems o be a library used for "build". Its high-level interface 
has been deprecated in favor for "build".

I as just about to write "So, while this might be one road to go, this 
is not of much use for us yet.". Anyhow, this might be a good base for 
pep517 based packages. On the other hand: Maybe we'd better stick with 
"pip wheel" and "pip install", see above.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2020-11-08 20:43 ` Michael Rohleder
@ 2020-11-10  8:30   ` Tanguy Le Carrour
  0 siblings, 0 replies; 23+ messages in thread
From: Tanguy Le Carrour @ 2020-11-10  8:30 UTC (permalink / raw)
  To: Michael Rohleder; +Cc: Guix

Hi Michael,


Le 11/08, Michael Rohleder a écrit :
> Tanguy Le Carrour <tanguy@bioneland.org> writes:
> > I've just learned, by accident (working on `python-keyring` [1]), that
> > `python setup.py install` was somehow deprecated in favor of tools like
> > `pep517` or `build`.
> >
> > So, I've tried packaging `python-keyring` with those two…
>
> apropos python-keyring:
>
> I also tried to update that package (in order to package "pantalaimon"
> which needs this) [1]
> The problem with this thing is, it wants to install an egginfo with
> version 0.0.0, no matter if build with setup.py or poetry [2]
>
> I tried debugging^Whacking this a while (eg. updateing setuptools, as
> suggested in the ticket), but couldn't make it work.
> If you find a solution, I'd be interested ;)
>
> Footnotes:
> [1] https://rohleder.de/gitweb/?p=guix.git;a=blob;f=mroh/guix/packages/python.scm;h=0c847795375ce08ca878727f15fd1a1b156df6f7;hb=HEAD#l533
> [2] https://github.com/jaraco/keyring/issues/469

Good to know that I'm not alone, thanks. I'll keep you posted!

-- 
Tanguy


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2020-11-08 17:05 ` Leo Famulari
@ 2020-11-10  8:35   ` Tanguy Le Carrour
  0 siblings, 0 replies; 23+ messages in thread
From: Tanguy Le Carrour @ 2020-11-10  8:35 UTC (permalink / raw)
  To: Leo Famulari; +Cc: Guix

Hi Leo,


Le 11/08, Leo Famulari a écrit :
> On Sun, Nov 08, 2020 at 03:27:17PM +0100, Tanguy Le Carrour wrote:
> > `pep517` keeps on trying to download dependencies, which won't work.
>
> That usually means that the software is missing some dependencies. If
> you think they should be available in the build environment,
> double-check that they are, and then look into how the software is
> looking for them.

I'll check and double check!


> > `build` crashes with "ZIP does not support timestamps before 1980",
> > which, I guess is related to the fact that everything in the store is
> > timestamped to January 1st 1970.
> 
> Are you using the python-build-system? It should handle this problem
> with its 'ensure-no-mtimes-pre-1980' phase.

Good to know, thanks! I'll read more about this 'ensure-no-mtimes-pre-1980'
phase.


> If will help if you share your package definition.

I'll work a bit more on it based on your answers guys and post a WIP to
guix-devel.

Regards

-- 
Tanguy


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2020-11-09 16:54 ` Hartmut Goebel
@ 2020-11-10  8:47   ` Tanguy Le Carrour
  2020-11-10  8:53     ` Hartmut Goebel
  0 siblings, 1 reply; 23+ messages in thread
From: Tanguy Le Carrour @ 2020-11-10  8:47 UTC (permalink / raw)
  To: Hartmut Goebel; +Cc: guix-devel

Hi Hartmut,


Le 11/09, Hartmut Goebel a écrit :
> seems like another messages of mine, regarding the first thread  about a
> poetry build system, did not make it to the list.
> 
> Am 08.11.20 um 15:27 schrieb Tanguy Le Carrour:
> > I've just learned, by accident (working on `python-keyring` [1]), that
> > `python setup.py install` was somehow deprecated
> 
> This statement is not exactly true - well, depending on interpretation of
> "somehow". I've not set seen an official deprecation.

Neither did I! But things are changing (fast) and it seems that I'm
always the last one to know! ^_^'


> It's true that users are encouraged to use pip for installing packages. But
> the official Python Packaging Tutorial [1] is still based on setuptools (not
> even recommending a setup.cfg file). Thus setuptools will be around for
> quite some more time, as will "python setup.py install".
> 
> [1] https://packaging.python.org/tutorials/packaging-projects/
>
> In the future Python world, any build-tool can be specified in
> "pyproject.toml". User will then call "pip install", and pip will (AFAIU)
> call a Python function (aka entry-point) specified in that file. (If this
> file does not exist, setuptools are assumed). For our python-build-system,
> we would use "pip wheel" (for phase build) and "pip install" (for phase
> install).
> 
> So, if we switch to "pip wheel" and "pip install", different python build
> systems could share a common base, just redefining some dependencies
> (setuptools, poetry, build, ...) and some tool-dependent flags. Is this the
> direction you are working towards?

I cannot say that, at the moment, I'm working in any particular direction!
… I'm just trying to make "it" work and learn a bit about Guix packaging
and Python along the way.

Actually, I'm not even yet sure that Poetry needs a dedicated build system,
as it also relies on a build-backend (defined in `pyproject.toml`) which
just happened to be `poetry.core.masonry`, but could be another one… I
guess, I'm not sure yet.

So, definitively a WIP!


> > in favor of tools like`pep517` or `build`.
> 
> Thanks for point to these, both are new to me.
> 
> "build" sounds interesting, esp. for guix: "It is a simple build tool and
> does not perform any dependency management." This would help us spliting
> dependency management and build phase. Anyhow, it's quite new (half an year
> old) and implements a PEP 517 package builder - and PEP 517 (defining the
> build system in pyproject.toml) is not yet adopted widely.
> 
> "pep517" seems o be a library used for "build". Its high-level interface has
> been deprecated in favor for "build".
> 
> I as just about to write "So, while this might be one road to go, this is
> not of much use for us yet.". Anyhow, this might be a good base for pep517
> based packages. On the other hand: Maybe we'd better stick with "pip wheel"
> and "pip install", see above.

+1! I'll try to make those packages who need a special build system
(which might be the case for `keyring`) work and see for a more
general "new" `python-build-system` later! And if I happen to learn
something on the way… great! :-)

Regards

-- 
Tanguy


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2020-11-10  8:47   ` Tanguy Le Carrour
@ 2020-11-10  8:53     ` Hartmut Goebel
  0 siblings, 0 replies; 23+ messages in thread
From: Hartmut Goebel @ 2020-11-10  8:53 UTC (permalink / raw)
  To: Tanguy Le Carrour; +Cc: guix-devel

Hi Tanguy,

Am 10.11.20 um 09:47 schrieb Tanguy Le Carrour:

> Actually, I'm not even yet sure that Poetry needs a dedicated build system,
> as it also relies on a build-backend (defined in `pyproject.toml`) which
> just happened to be `poetry.core.masonry`, but could be another one… I
> guess, I'm not sure yet.

This sounds like it is meant to be build and installed using one of the 
PEP-517 compatible tools, e.g. "pip wheel" & "pip install".


> +1! I'll try to make those packages who need a special build system
> (which might be the case for `keyring`) work and see for a more
> general "new" `python-build-system` later! And if I happen to learn
> something on the way… great! :-)

Sounds good :-)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2020-11-08 14:27 Questions regarding Python packaging Tanguy Le Carrour
                   ` (2 preceding siblings ...)
  2020-11-09 16:54 ` Hartmut Goebel
@ 2021-01-05 10:25 ` Lars-Dominik Braun
  2021-01-06 15:32   ` Tanguy LE CARROUR
  2021-01-06 15:37   ` Tanguy LE CARROUR
  3 siblings, 2 replies; 23+ messages in thread
From: Lars-Dominik Braun @ 2021-01-05 10:25 UTC (permalink / raw)
  To: Tanguy Le Carrour; +Cc: Guix

Hi Tanguy,

> So, I've tried packaging `python-keyring` with those two…
> 
> `pep517` keeps on trying to download dependencies, which won't work.
> 
> `build` crashes with "ZIP does not support timestamps before 1980",
> which, I guess is related to the fact that everything in the store is
> timestamped to January 1st 1970.
have you been looking into a python-build-system using `build`[1]? I’ve
had the same issue with egg versions set to 0.0.0 and think in the long
run moving to a PEP 517-style build is the way forward.

Cheers,
Lars

[1] https://github.com/pypa/build



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2021-01-05 10:25 ` Lars-Dominik Braun
@ 2021-01-06 15:32   ` Tanguy LE CARROUR
  2021-01-22  8:38     ` Tanguy LE CARROUR
  2021-01-06 15:37   ` Tanguy LE CARROUR
  1 sibling, 1 reply; 23+ messages in thread
From: Tanguy LE CARROUR @ 2021-01-06 15:32 UTC (permalink / raw)
  To: Lars-Dominik Braun; +Cc: Guix

Hi Lars,


Excerpts from Lars-Dominik Braun's message of January 5, 2021 11:25 am:
> Hi Tanguy,
> 
>> So, I've tried packaging `python-keyring` with those two…
>> 
>> `pep517` keeps on trying to download dependencies, which won't work.
>> 
>> `build` crashes with "ZIP does not support timestamps before 1980",
>> which, I guess is related to the fact that everything in the store is
>> timestamped to January 1st 1970.
> have you been looking into a python-build-system using `build`[1]? I’ve
> had the same issue with egg versions set to 0.0.0 and think in the long
> run moving to a PEP 517-style build is the way forward.

I agree! Unfortunately, I haven't had much time (so far) to work on it! :-(

I'll revive the thread as soon as I've made progress…

Regards!

-- 
Tanguy



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2021-01-05 10:25 ` Lars-Dominik Braun
  2021-01-06 15:32   ` Tanguy LE CARROUR
@ 2021-01-06 15:37   ` Tanguy LE CARROUR
  1 sibling, 0 replies; 23+ messages in thread
From: Tanguy LE CARROUR @ 2021-01-06 15:37 UTC (permalink / raw)
  To: Lars-Dominik Braun; +Cc: Guix

Excerpts from Lars-Dominik Braun's message of January 5, 2021 11:25 am:
> Hi Tanguy,
> 
>> So, I've tried packaging `python-keyring` with those two…
>> 
>> `pep517` keeps on trying to download dependencies, which won't work.
>> 
>> `build` crashes with "ZIP does not support timestamps before 1980",
>> which, I guess is related to the fact that everything in the store is
>> timestamped to January 1st 1970.
> have you been looking into a python-build-system using `build`[1]? I’ve
> had the same issue with egg versions set to 0.0.0 and think in the long
> run moving to a PEP 517-style build is the way forward.

Actually —and I almost forgot!—, Sébastien found a solution to our "0.0.0" problem:
https://github.com/jaraco/keyring/issues/469#issuecomment-735695476

-- 
Tanguy


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2021-01-06 15:32   ` Tanguy LE CARROUR
@ 2021-01-22  8:38     ` Tanguy LE CARROUR
  2021-01-23 12:34       ` Lars-Dominik Braun
  2021-01-26  7:21       ` Tanguy LE CARROUR
  0 siblings, 2 replies; 23+ messages in thread
From: Tanguy LE CARROUR @ 2021-01-22  8:38 UTC (permalink / raw)
  To: Lars-Dominik Braun, Guix

Hi Guix, hi Lars,


Excerpts from Tanguy LE CARROUR's message of January 6, 2021 4:32 pm:
> Excerpts from Lars-Dominik Braun's message of January 5, 2021 11:25 am:
>>> So, I've tried packaging `python-keyring` with those two…
>>> 
>>> `pep517` keeps on trying to download dependencies, which won't work.
>>> 
>>> `build` crashes with "ZIP does not support timestamps before 1980",
>>> which, I guess is related to the fact that everything in the store is
>>> timestamped to January 1st 1970.
>> have you been looking into a python-build-system using `build`[1]? I’ve
>> had the same issue with egg versions set to 0.0.0 and think in the long
>> run moving to a PEP 517-style build is the way forward.
> 
> I agree! Unfortunately, I haven't had much time (so far) to work on it! :-(
> 
> I'll revive the thread as soon as I've made progress…

Done! :-)
I've eventually succeeded in ("properly") packaging a software managed
with Poetry. And I've learned quite a lot on the way!

Following Efraim's presentation on Guix Day, I've added a `guix.scm`
file to one of my pet projects. Any Guix user should be able to build it.

```bash
$ git clone https://gitlab.com/TanguyEE/nowty.git
Cloning into 'nowty'...
[…]

$ cd nowty/
$ guix build --file=guix.scm
[…]
successfully built /gnu/store/[…]-nowty-0.1.0a0+2d656ef.drv
/gnu/store/[…]-nowty-0.1.0a0+2d656ef

$ /gnu/store/[…]-nowty-0.1.0a0+2d656ef/bin/nowty
'High Hopes' from album 'Pray for the Wicked' by 'Panic! at the Disco'.
```

Regarding the package definition:
- the `build` phase updates the package version in `pyproject.toml` ;
- the `install` phase uses `pip` which in turn uses the build system
  from `poetry-core`.

I know that the phase names don't make much sense! … but it's a
work in progress ! :-)

Any comment welcome.

Regards,

-- 
Tanguy



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2021-01-22  8:38     ` Tanguy LE CARROUR
@ 2021-01-23 12:34       ` Lars-Dominik Braun
  2021-01-24 13:30         ` Tanguy LE CARROUR
                           ` (3 more replies)
  2021-01-26  7:21       ` Tanguy LE CARROUR
  1 sibling, 4 replies; 23+ messages in thread
From: Lars-Dominik Braun @ 2021-01-23 12:34 UTC (permalink / raw)
  To: Tanguy LE CARROUR; +Cc: Guix

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

Hi Tanguy,

> Done! :-)
> I've eventually succeeded in ("properly") packaging a software managed
> with Poetry. And I've learned quite a lot on the way!
oh, I see. I’ve actually been trying to replace python-build-system with
a python-build based build. Attached is my current work in progress. I
cannot quite build python-build, because I’m lacking support for
python-flit, but I think the general idea is clear: Remove pip and
setuptools from python (saves almost 20MiB from the closure and avoids
weird conflicts between python’s setuptools and python-setuptools) and
turn them into (almost) ordinary packages. Then use setuptools to
bootstrap itself, bootstrap python-build with setuptools and use
python-build to build evrey other packages using python-build-system.

Cheers,
Lars


[-- Attachment #2: wip-pep-517-build.diff --]
[-- Type: text/plain, Size: 30148 bytes --]

diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index d08e23936c..a9843bd9cb 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -1123,14 +1123,14 @@ other machines, such as over the network.")
 (define-public python-setuptools
   (package
     (name "python-setuptools")
-    (version "41.0.1")
+    (version "51.3.1")
     (source
      (origin
       (method url-fetch)
-      (uri (pypi-uri "setuptools" version ".zip"))
+      (uri (pypi-uri "setuptools" version))
       (sha256
        (base32
-        "04sns22y2hhsrwfy1mha2lgslvpjsjsz8xws7h2rh5a7ylkd28m2"))
+        "07qk6ykhq1q4k33x1m96r39f9qpfzp2xfl5ly9zww0180gssrvqc"))
       (modules '((guix build utils)))
       (snippet
        '(begin
@@ -1143,7 +1143,26 @@ other machines, such as over the network.")
     ;; FIXME: Tests require pytest, which itself relies on setuptools.
     ;; One could bootstrap with an internal untested setuptools.
     (arguments
-     `(#:tests? #f))
+     `(#:tests? #f
+       #:need-setuptools #f
+       #:python-build-variant #f
+       #:phases (modify-phases %standard-phases
+                  (replace 'build
+                           (lambda _
+                             (invoke "python" "setup.py" "build")))
+                  (replace 'install
+                           (lambda* (#:key outputs #:allow-other-keys)
+                             (let ((out (assoc-ref outputs "out")))
+                             (invoke "python" "setup.py" "install" "--prefix" out "--single-version-externally-managed" "--root=/"))))
+                  ;; Use this setuptools’ sources to bootstrap themselves.
+                  (add-before 'build 'set-PYTHONPATH
+                    (lambda _
+                      (format #t "current working dir ~s~%" (getcwd))
+                      (setenv "PYTHONPATH"
+                              (string-append ".:" (getenv "PYTHONPATH")))
+                      #t)))))
+    ;; Not required when not building a wheel
+    ;(propagated-inputs `(("python-wheel" ,python-wheel)))
     (home-page "https://pypi.org/project/setuptools/")
     (synopsis
      "Library designed to facilitate packaging Python projects")
@@ -1822,7 +1841,7 @@ Python file, so it can be easily copied into your project.")
   (package
     (inherit python-six)
     (name "python-six-bootstrap")
-    (native-inputs `())
+    (native-inputs '())
     (arguments `(#:tests? #f))))
 
 (define-public python2-six-bootstrap
@@ -5675,7 +5694,8 @@ by pycodestyle.")
              ;; NOTE: Any value works, the variable just has to be present.
              (setenv "SKIP_ONLINE" "1")
              #t)))))
-    (native-inputs `(("unzip" ,unzip)))
+    (native-inputs
+      `(("unzip" ,unzip)))
     (home-page "https://bitbucket.org/pypa/distlib")
     (synopsis "Distribution utilities")
     (description "Distlib is a library which implements low-level functions that
@@ -15272,7 +15292,7 @@ protocols.")
   (package
     (inherit python-attrs)
     (name "python-attrs-bootstrap")
-    (native-inputs `())
+    (native-inputs '())
     (arguments `(#:tests? #f))))
 
 (define-public python2-attrs-bootstrap
@@ -23451,3 +23471,292 @@ Qt applications.")
       "Pivy provides python bindings for Coin, a 3D graphics library with an
 Application Programming Interface based on the Open Inventor 2.1 API.")
     (license license:isc)))
+
+(define-public python-build
+  (package
+    (name "python-build")
+    (version "0.1.0")
+    (source
+      (origin
+        (method url-fetch)
+        (uri (pypi-uri "build" version))
+        (sha256
+          (base32
+            "1d6m21lijwm04g50nwgsgj7x3vhblzw7jv05ah8psqgzk20bbch8"))))
+    (build-system python-build-system)
+    (arguments `(#:python-build-variant ,python-build-bootstrap))
+    (propagated-inputs
+      `(("python-packaging" ,python-packaging)
+        ("python-pep517" ,python-pep517)
+        ("python-toml" ,python-toml)
+        ;; For fallback option.
+        ("python-setuptools" ,python-setuptools)))
+    (native-inputs
+      `(("python-filelock" ,python-filelock)
+        ("python-pytest" ,python-pytest)
+        ("python-pytest-cov" ,python-pytest-cov)
+        ("python-pytest-mock" ,python-pytest-mock)
+        ("python-pytest-xdist" ,python-pytest-xdist)))
+    (home-page "https://pypa-build.readthedocs.io/")
+    (synopsis
+      "A simple, correct PEP517 package builder")
+    (description
+      "A simple, correct PEP517 package builder")
+    (license license:expat)))
+
+(define-public python-pep517-bootstrap
+               (package
+                 (inherit python-pep517)
+                 (name "python-pep517-bootstrap")
+                 (arguments `(#:tests? #f))
+                 (native-inputs `())))
+
+(define-public python-build-bootstrap
+  (package
+    (name "python-build-bootstrap")
+    (version "0.1.0")
+    (source
+      (origin
+        (method url-fetch)
+        (uri (pypi-uri "build" version))
+        (sha256
+          (base32
+            "1d6m21lijwm04g50nwgsgj7x3vhblzw7jv05ah8psqgzk20bbch8"))))
+    (build-system python-build-system)
+    (arguments
+     `(#:tests? #f
+       #:python-build-variant #f
+       #:phases (modify-phases %standard-phases
+                  (replace 'build
+                           (lambda _
+                             (invoke "python" "setup.py" "build")))
+                  (replace 'install
+                           (lambda* (#:key outputs #:allow-other-keys)
+                             (let ((out (assoc-ref outputs "out")))
+                             (invoke "python" "setup.py" "install" "--prefix" out "--single-version-externally-managed" "--root=/")))))))
+    (propagated-inputs
+      `(("python-pep517" ,python-pep517-source-bootstrap)
+        ("python-packaging" ,python-packaging-source-bootstrap)))
+    (home-page "https://pypa-build.readthedocs.io/")
+    (synopsis
+      "A simple, correct PEP517 package builder")
+    (description
+      "A simple, correct PEP517 package builder")
+    (license license:expat)))
+
+(define-public python-pep517-source-bootstrap
+  (package
+    (name "python-pep517-source-bootstrap")
+    (version "0.9.1")
+    (source
+      (origin
+        (method url-fetch)
+        (uri (pypi-uri "pep517" version))
+        (sha256
+         (base32
+          "0zqidxah03qpnp6zkg3zd1kmd5f79hhdsfmlc0cldaniy80qddxf"))))
+    (build-system python-build-system)
+    (arguments
+     `(#:tests? #f
+       #:python-build-variant #f
+       #:phases (modify-phases %standard-phases
+(add-after 'unpack 'patch
+           (lambda _
+             (substitute* "setup.py"
+               (("distutils\\.core") "setuptools"))
+             #t))
+                  (replace 'build
+                           (lambda _
+                             (invoke "python" "setup.py" "build")))
+                  (replace 'install
+                           (lambda* (#:key outputs #:allow-other-keys)
+                             (let ((out (assoc-ref outputs "out")))
+                             (invoke "python" "setup.py" "install" "--prefix" out "--single-version-externally-managed" "--root=/")))))))
+    (propagated-inputs
+     `(("python-toml" ,python-toml-source-bootstrap)
+       ("python-wheel" ,python-wheel-bootstrap)
+       ))
+    (home-page "https://github.com/pypa/pep517")
+    (synopsis "Wrappers to build Python packages using PEP 517 hooks")
+    (description
+     "Wrappers to build Python packages using PEP 517 hooks.")
+    (license license:expat)))
+
+(define-public python-toml-source-bootstrap
+  (package
+    (name "python-toml-source-bootstrap")
+    (version "0.10.1")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (pypi-uri "toml" version))
+       (sha256
+        (base32
+         "03wbqm5cn685cwx2664hjdpz370njl7lf0yal8s0dkp5w4mn2swj"))))
+    (build-system python-build-system)
+    (arguments
+     `(#:tests? #f
+       #:python-build-variant #f
+       #:phases (modify-phases %standard-phases
+                  (replace 'build
+                           (lambda _
+                             (invoke "python" "setup.py" "build")))
+                  (replace 'install
+                           (lambda* (#:key outputs #:allow-other-keys)
+                             (let ((out (assoc-ref outputs "out")))
+                             (invoke "python" "setup.py" "install" "--prefix" out "--single-version-externally-managed" "--root=/")))))))
+    (home-page "https://github.com/uiri/toml")
+    (synopsis "Library for TOML")
+    (description
+     "@code{toml} is a library for parsing and creating Tom's Obvious, Minimal
+Language (TOML) configuration files.")
+    (license license:expat)))
+
+(define-public python-packaging-source-bootstrap
+  (package
+    (name "python-packaging-source-bootstrap")
+    (version "20.0")
+    (source
+      (origin
+        (method url-fetch)
+        (uri (pypi-uri "packaging" version))
+        ;; XXX: The URL in the patch file is wrong, it should be
+        ;; <https://github.com/pypa/packaging/pull/256>.
+        (patches (search-patches "python-packaging-test-arch.patch"))
+        (sha256
+         (base32
+          "1y2ip3a4ykkpgnwgn85j6hkspcl0cg3mzms97f40mk57vwqq67gy"))))
+    (build-system python-build-system)
+    (arguments
+     `(#:tests? #f
+       #:python-build-variant #f
+       #:phases (modify-phases %standard-phases
+                  (replace 'build
+                           (lambda _
+                             (invoke "python" "setup.py" "build")))
+                  (replace 'install
+                           (lambda* (#:key outputs #:allow-other-keys)
+                             (let ((out (assoc-ref outputs "out")))
+                             (invoke "python" "setup.py" "install" "--prefix" out "--single-version-externally-managed" "--root=/")))))))
+    (propagated-inputs
+     `(("python-pyparsing" ,python-pyparsing-bootstrap)
+       ("python-six" ,python-six-bootstrap2)
+       ))
+    (home-page "https://github.com/pypa/packaging")
+    (synopsis "Core utilities for Python packages")
+    (description "Packaging is a Python module for dealing with Python packages.
+It offers an interface for working with package versions, names, and dependency
+information.")
+    ;; From 'LICENSE': This software is made available under the terms of
+    ;; *either* of the licenses found in LICENSE.APACHE or LICENSE.BSD.
+    ;; Contributions to this software is made under the terms of *both* these
+    ;; licenses.
+    (license (list license:asl2.0 license:bsd-2))))
+
+(define-public python-pyparsing-bootstrap
+  (package
+    (name "python-pyparsing-bootstrap")
+    (version "2.4.6")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (pypi-uri "pyparsing" version))
+       (sha256
+        (base32 "17wn5zlijc9m9zj26gy3f541y7smpj8rfhl51d025c2gm210b0sc"))))
+    (build-system python-build-system)
+    (arguments
+     `(#:tests? #f
+       #:python-build-variant #f
+       #:phases (modify-phases %standard-phases
+                  (replace 'build
+                           (lambda _
+                             (invoke "python" "setup.py" "build")))
+                  (replace 'install
+                           (lambda* (#:key outputs #:allow-other-keys)
+                             (let ((out (assoc-ref outputs "out")))
+                             (invoke "python" "setup.py" "install" "--prefix" out "--single-version-externally-managed" "--root=/")))))))
+    (home-page "https://github.com/pyparsing/pyparsing")
+    (synopsis "Python parsing class library")
+    (description
+     "The pyparsing module is an alternative approach to creating and
+executing simple grammars, vs. the traditional lex/yacc approach, or the use
+of regular expressions.  The pyparsing module provides a library of classes
+that client code uses to construct the grammar directly in Python code.")
+    (license license:expat)))
+
+(define-public python-six-bootstrap2
+  (package
+    (name "python-six-bootstrap")
+    (version "1.14.0")
+    (source
+     (origin
+      (method url-fetch)
+      (uri (pypi-uri "six" version))
+      (sha256
+       (base32
+        "02lw67hprv57hyg3cfy02y3ixjk3nzwc0dx3c4ynlvkfwkfdnsr3"))))
+    (build-system python-build-system)
+    (arguments
+     `(#:tests? #f
+       #:python-build-variant #f
+       #:phases (modify-phases %standard-phases
+                  (replace 'build
+                           (lambda _
+                             (invoke "python" "setup.py" "build")))
+                  (replace 'install
+                           (lambda* (#:key outputs #:allow-other-keys)
+                             (let ((out (assoc-ref outputs "out")))
+                             (invoke "python" "setup.py" "install" "--prefix" out "--single-version-externally-managed" "--root=/")))))))
+    (home-page "https://pypi.org/project/six/")
+    (synopsis "Python 2 and 3 compatibility utilities")
+    (description
+     "Six is a Python 2 and 3 compatibility library.  It provides utility
+functions for smoothing over the differences between the Python versions with
+the goal of writing Python code that is compatible on both Python versions.
+Six supports every Python version since 2.5.  It is contained in only one
+Python file, so it can be easily copied into your project.")
+    (license license:x11)))
+
+(define-public python-wheel-bootstrap
+  (package
+    (name "python-wheel-bootstrap")
+    (version "0.33.6")
+    (source
+      (origin
+        (method url-fetch)
+        (uri (pypi-uri "wheel" version))
+        (sha256
+         (base32
+          "0ii6f34rvpjg3nmw4bc2h7fhdsy38y1h93hghncfs5akfrldmj8h"))))
+    (build-system python-build-system)
+    (arguments
+     `(#:tests? #f
+       #:python-build-variant #f
+       #:phases (modify-phases %standard-phases
+(add-after 'unpack 'patch-enable-entrypoints
+           (lambda _
+             ;; python-wheel tells setuptools to not install entry point scripts
+             ;; by default. Stop doing that, so wheels built contain all data
+             ;; required.
+             (substitute* "wheel/bdist_wheel.py"
+               (("(install_scripts\\.no_ep = )True" all assignment) (string-append assignment "False")))
+             #t))
+                  (replace 'build
+                           (lambda _
+                             (invoke "python" "setup.py" "build")))
+                  (replace 'install
+                           (lambda* (#:key outputs #:allow-other-keys)
+                             (let ((out (assoc-ref outputs "out")))
+                             (invoke "python" "setup.py" "install" "--prefix" out "--single-version-externally-managed" "--root=/")))))))
+    (home-page "https://bitbucket.org/pypa/wheel/")
+    (synopsis "Format for built Python packages")
+    (description
+     "A wheel is a ZIP-format archive with a specially formatted filename and
+the @code{.whl} extension.  It is designed to contain all the files for a PEP
+376 compatible install in a way that is very close to the on-disk format.  Many
+packages will be properly installed with only the @code{Unpack} step and the
+unpacked archive preserves enough information to @code{Spread} (copy data and
+scripts to their final locations) at any later time.  Wheel files can be
+installed with a newer @code{pip} or with wheel's own command line utility.")
+    (license license:expat)))
+
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index fa9bf10e07..57221a91ea 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -100,6 +100,7 @@
   #:use-module (guix utils)
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system trivial)
+  #:use-module (guix build-system copy)
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-26))
 
@@ -153,7 +154,7 @@
        (list "--enable-shared"                    ;allow embedding
              "--with-system-expat"                ;for XML support
              "--with-system-ffi"                  ;build ctypes
-             "--with-ensurepip=install"           ;install pip and setuptools
+             "--with-ensurepip=no"                ;do not install pip and setuptools
              "--enable-unicode=ucs4"
 
              ;; Prevent the installed _sysconfigdata.py from retaining a reference
@@ -874,4 +875,12 @@ Python code natively, including C extensions.")
                    license:bsd-3 ; lib_pypy/cffi/_pycparser/ply/
                    (license:non-copyleft
                     "http://www.unicode.org/copyright.html")))))
+(define* (pypi-uri name version #:optional (extension ".tar.gz"))
+  "Return a URI string for the Python package hosted on the Python Package
+Index (PyPI) corresponding to NAME and VERSION.  EXTENSION is the file name
+extension, such as '.tar.gz'."
+  (string-append "https://files.pythonhosted.org/packages/source/"
+                 (string-take name 1) "/" name "/"
+                 name "-" version extension))
+
 
diff --git a/gnu/packages/xml.scm b/gnu/packages/xml.scm
index 930cd795f5..2af62d59df 100644
--- a/gnu/packages/xml.scm
+++ b/gnu/packages/xml.scm
@@ -64,6 +64,7 @@
   #:use-module (gnu packages perl)
   #:use-module (gnu packages perl-check)
   #:use-module (gnu packages python)
+  #:use-module (gnu packages python-xyz)
   #:use-module (gnu packages tls)
   #:use-module (gnu packages web)
   #:use-module ((guix licenses) #:prefix license:)
@@ -2391,6 +2392,7 @@ The central program included in this package is @code{onsgmls}, which replaces
         (base32
          "15h7d41v48q31hzjay7qzixdv531hnga3h35hksk7x52pgqcrkz7"))))
     (build-system python-build-system)
+    (native-inputs `(("python-setuptools" ,python-setuptools)))
     (home-page
      "https://github.com/sissaschool/elementpath")
     (synopsis
@@ -2416,13 +2418,20 @@ because lxml.etree already has it's own implementation of XPath 1.0.")
         (base32 "01nvb5j8vs9nk4z5s3250b1m22b4d08kffa36if3g1mdygdrvxpg"))))
     (build-system python-build-system)
     (arguments
-     `(#:phases (modify-phases %standard-phases
-                  (replace 'check
+      `(#:phases (modify-phases %standard-phases
+                                ;; Expects setup.py to be called from source root.
+         (add-after 'unpack 'patch-get-base-dir
                     (lambda _
-                      (invoke "make" "test"))))))
+                      (substitute* "versioninfo.py"
+                                   (("os.path.abspath\\(os.path.dirname\\(sys.argv\\[0\\]\\)\\)") "'.'"))
+                      #t))
+         (replace 'check
+                  (lambda _
+                    (invoke "make" "test"))))))
     (inputs
      `(("libxml2" ,libxml2)
        ("libxslt" ,libxslt)))
+    (native-inputs `(("python-setuptools" ,python-setuptools)))
     (home-page "https://lxml.de/")
     (synopsis "Python XML processing library")
     (description
diff --git a/guix/build-system/python.scm b/guix/build-system/python.scm
index e39c06528e..6a9f40faa4 100644
--- a/guix/build-system/python.scm
+++ b/guix/build-system/python.scm
@@ -70,6 +70,16 @@ extension, such as '.tar.gz'."
   (let ((python (resolve-interface '(gnu packages python))))
     (module-ref python 'python-2)))
 
+(define (default-python-build)
+  "Return the default Python 2 package."
+  (let ((python (resolve-interface '(gnu packages python-xyz))))
+    (module-ref python 'python-build-bootstrap)))
+
+(define (default-python-setuptools)
+  "Return the default Python 2 package."
+  (let ((python (resolve-interface '(gnu packages python-xyz))))
+    (module-ref python 'python-setuptools)))
+
 (define* (package-with-explicit-python python old-prefix new-prefix
                                        #:key variant-property)
   "Return a procedure of one argument, P.  The procedure creates a package with
@@ -138,11 +148,13 @@ pre-defined variants."
 (define* (lower name
                 #:key source inputs native-inputs outputs system target
                 (python (default-python))
+                (python-build-variant (default-python-build))
+				(need-setuptools #t)
                 #:allow-other-keys
                 #:rest arguments)
   "Return a bag for NAME."
   (define private-keywords
-    '(#:source #:target #:python #:inputs #:native-inputs))
+    '(#:source #:target #:python #:python-build-variant #:need-setuptools #:inputs #:native-inputs))
 
   (and (not target)                               ;XXX: no cross-compilation
        (bag
@@ -156,6 +168,15 @@ pre-defined variants."
                         ;; Keep the standard inputs of 'gnu-build-system'.
                         ,@(standard-packages)))
          (build-inputs `(("python" ,python)
+                         ,@(if python-build-variant
+							`(("python-build" ,python-build-variant))
+							'())
+						 ;; Most packages still use setuptools and *all* of our
+						 ;; packages assume it’s available, so include it
+						 ;; except when bootstrapping.
+						 ,@(if need-setuptools
+							 `(("python-setuptools" ,(default-python-setuptools)))
+							 '())
                          ,@native-inputs))
          (outputs outputs)
          (build python-build)
@@ -164,8 +185,6 @@ pre-defined variants."
 (define* (python-build store name inputs
                        #:key
                        (tests? #t)
-                       (test-target "test")
-                       (use-setuptools? #t)
                        (configure-flags ''())
                        (phases '(@ (guix build python-build-system)
                                    %standard-phases))
@@ -191,9 +210,7 @@ provides a 'setup.py' file as its build system."
                                   source))
                      #:configure-flags ,configure-flags
                      #:system ,system
-                     #:test-target ,test-target
                      #:tests? ,tests?
-                     #:use-setuptools? ,use-setuptools?
                      #:phases ,phases
                      #:outputs %outputs
                      #:search-paths ',(map search-path-specification->sexp
diff --git a/guix/build/python-build-system.scm b/guix/build/python-build-system.scm
index 09bd8465c8..750c2d33f7 100644
--- a/guix/build/python-build-system.scm
+++ b/guix/build/python-build-system.scm
@@ -104,47 +104,18 @@
 ;; and the scripts defined in entry-points will always be created.
 
 
-(define setuptools-shim
-  ;; Run setup.py with "setuptools" being imported, which will patch
-  ;; "distutils". This is needed for packages using "distutils" instead of
-  ;; "setuptools" since the former does not understand the
-  ;; "--single-version-externally-managed" flag.
-  ;; Python code taken from pip 9.0.1 pip/utils/setuptools_build.py
-  (string-append
-   "import setuptools, tokenize;__file__='setup.py';"
-   "f=getattr(tokenize, 'open', open)(__file__);"
-   "code=f.read().replace('\\r\\n', '\\n');"
-   "f.close();"
-   "exec(compile(code, __file__, 'exec'))"))
-
-(define (call-setuppy command params use-setuptools?)
-  (if (file-exists? "setup.py")
-      (begin
-         (format #t "running \"python setup.py\" with command ~s and parameters ~s~%"
-                command params)
-         (if use-setuptools?
-             (apply invoke "python" "-c" setuptools-shim
-                    command params)
-             (apply invoke "python" "./setup.py" command params)))
-      (error "no setup.py found")))
-
-(define* (build #:key use-setuptools? #:allow-other-keys)
+(define* (build #:key outputs #:allow-other-keys)
   "Build a given Python package."
-  (call-setuppy "build" '() use-setuptools?)
+  ;; XXX: use "wheel" output instead?
+  (mkdir-p "dist")
+  (invoke "python" "-m" "build" "--outdir" "dist" "--no-isolation" "--wheel" ".")
   #t)
 
-(define* (check #:key tests? test-target use-setuptools? #:allow-other-keys)
+(define* (check #:key tests? #:allow-other-keys)
   "Run the test suite of a given Python package."
   (if tests?
-      ;; Running `setup.py test` creates an additional .egg-info directory in
-      ;; build/lib in some cases, e.g. if the source is in a sub-directory
-      ;; (given with `package_dir`). This will by copied to the output, too,
-      ;; so we need to remove.
-      (let ((before (find-files "build" "\\.egg-info$" #:directories? #t)))
-        (call-setuppy test-target '() use-setuptools?)
-        (let* ((after (find-files "build" "\\.egg-info$" #:directories? #t))
-               (inter (lset-difference string=? after before)))
-          (for-each delete-file-recursively inter)))
+    ;; XXX: Choose testing util based on native inputs?
+      (format #t "fixme")
       (format #t "test suite not run~%"))
   #t)
 
@@ -172,18 +143,38 @@ when running checks after installing the package."
                            (if old-path (string-append ":" old-path) "")))
     #t))
 
-(define* (install #:key outputs (configure-flags '()) use-setuptools?
-                  #:allow-other-keys)
+(define* (install #:key inputs outputs (configure-flags '()) #:allow-other-keys)
   "Install a given Python package."
-  (let* ((out (assoc-ref outputs "out"))
-         (params (append (list (string-append "--prefix=" out))
-                         (if use-setuptools?
-                             ;; distutils does not accept these flags
-                             (list "--single-version-externally-managed"
-                                    "--root=/")
-                             '())
-                         configure-flags)))
-    (call-setuppy "install" params use-setuptools?)
+  (let* ((site-dir (site-packages inputs outputs))
+         (out (assoc-ref outputs "out"))
+         (wheels (find-files "dist" "\\.whl$")))
+	(define (extract file)
+      ;; Use Python’s zipfile to avoid extra dependency
+      ;; XXX: have to move data files according to PEP 517
+      (invoke "python3" "-m" "zipfile" "-e" file site-dir))
+
+    (for-each extract wheels)
+
+    ;; for scripts
+    (mkdir-p (string-append out "/bin"))
+	(let ((datadirs (find-files site-dir "\\.data$" #:directories? #t)))
+      (for-each (lambda (d)
+                  (for-each (lambda (f)
+                              (rename-file (string-append d "/scripts/" f) (string-append out "/bin/" (basename f)))
+                              ;; ZIP does not save/restore permissions, make executable, XXX: f might not be a file, but directory with subdirectories
+                              (chmod (string-append out "/bin/" (basename f)) #o755)
+                              (substitute* (string-append out "/bin/" (basename f))
+               (("#!python")
+                (string-append "#!" (assoc-ref inputs "python") "/bin/python"))))
+                            (scandir (string-append d "/scripts") (negate (cut member <> '("." "..")))))) datadirs))
+    #t))
+
+(define* (compile-bytecode #:key inputs outputs (configure-flags '()) #:allow-other-keys)
+  "Compile installed byte-code in site-packages."
+  (let ((site-dir (site-packages inputs outputs)))
+    ;; XXX: replace 0 with max allowed threads
+    (invoke "python3" "-m" "compileall" "-j" "0" site-dir)
+    ;; XXX: We could compile with -O and -OO too here, at the cost of more space.
     #t))
 
 (define* (wrap #:key inputs outputs #:allow-other-keys)
@@ -214,23 +205,6 @@ when running checks after installing the package."
               bindirs)
     #t))
 
-(define* (rename-pth-file #:key name inputs outputs #:allow-other-keys)
-  "Rename easy-install.pth to NAME.pth to avoid conflicts between packages
-installed with setuptools."
-  ;; Even if the "easy-install.pth" is not longer created, we kept this phase.
-  ;; There still may be packages creating an "easy-install.pth" manually for
-  ;; some good reason.
-  (let* ((out (assoc-ref outputs "out"))
-         (python (assoc-ref inputs "python"))
-         (site-packages (string-append out "/lib/python"
-                                       (python-version python)
-                                       "/site-packages"))
-         (easy-install-pth (string-append site-packages "/easy-install.pth"))
-         (new-pth (string-append site-packages "/" name ".pth")))
-    (when (file-exists? easy-install-pth)
-      (rename-file easy-install-pth new-pth))
-    #t))
-
 (define* (ensure-no-mtimes-pre-1980 #:rest _)
   "Ensure that there are no mtimes before 1980-01-02 in the source tree."
   ;; Rationale: patch-and-repack creates tarballs with timestamps at the POSIX
@@ -244,6 +218,13 @@ installed with setuptools."
                #t))
     #t))
 
+(define* (set-SOURCE-DATE-EPOCH #:rest _)
+  "Set the 'SOURCE_DATE_EPOCH' environment variable.  This is used by tools
+that incorporate timestamps as a way to tell them to use a fixed timestamp.
+See https://reproducible-builds.org/specs/source-date-epoch/."
+  (setenv "SOURCE_DATE_EPOCH" "315619200") ;; python-wheel respects this variable and sets pre-1980 times on files in zip files, which is unsupported
+  #t)
+
 (define* (enable-bytecode-determinism #:rest _)
   "Improve determinism of pyc files."
   ;; Use deterministic hashes for strings, bytes, and datetime objects.
@@ -260,14 +241,15 @@ installed with setuptools."
     (add-after 'unpack 'ensure-no-mtimes-pre-1980 ensure-no-mtimes-pre-1980)
     (add-after 'ensure-no-mtimes-pre-1980 'enable-bytecode-determinism
       enable-bytecode-determinism)
+    (replace 'set-SOURCE-DATE-EPOCH set-SOURCE-DATE-EPOCH)
     (delete 'bootstrap)
     (delete 'configure)                 ;not needed
     (replace 'build build)
     (delete 'check)                     ;moved after the install phase
     (replace 'install install)
     (add-after 'install 'check check)
-    (add-after 'install 'wrap wrap)
-    (add-before 'strip 'rename-pth-file rename-pth-file)))
+    (add-before 'check 'compile-bytecode compile-bytecode)
+    (add-after 'install 'wrap wrap)))
 
 (define* (python-build #:key inputs (phases %standard-phases)
                        #:allow-other-keys #:rest args)

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2021-01-23 12:34       ` Lars-Dominik Braun
@ 2021-01-24 13:30         ` Tanguy LE CARROUR
  2021-01-24 20:54         ` Ryan Prior
                           ` (2 subsequent siblings)
  3 siblings, 0 replies; 23+ messages in thread
From: Tanguy LE CARROUR @ 2021-01-24 13:30 UTC (permalink / raw)
  To: Lars-Dominik Braun; +Cc: Guix

Hi Lars,


Excerpts from Lars-Dominik Braun's message of January 23, 2021 1:34 pm:
>> Done! :-)
>> I've eventually succeeded in ("properly") packaging a software managed
>> with Poetry. And I've learned quite a lot on the way!
> oh, I see. I’ve actually been trying to replace python-build-system with
> a python-build based build. Attached is my current work in progress. I
> cannot quite build python-build, ,

?!
My `python-build` seems to work:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45931


> because I’m lacking support for python-flit

I also had a problem with `python-flit`, but it was when I was working
on `python-typer`:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45935

This is why I didn't build it from the source.


> but I think the general idea is clear: Remove pip and
> setuptools from python (saves almost 20MiB from the closure and avoids
> weird conflicts between python’s setuptools and python-setuptools) and
> turn them into (almost) ordinary packages. Then use setuptools to
> bootstrap itself, bootstrap python-build with setuptools and use
> python-build to build evrey other packages using python-build-system.

Wow, the rest is way out of my comfort zone! But I'll read it carefully
and try to help if I can!

Best regards,

-- 
Tanguy


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2021-01-23 12:34       ` Lars-Dominik Braun
  2021-01-24 13:30         ` Tanguy LE CARROUR
@ 2021-01-24 20:54         ` Ryan Prior
  2021-01-25 11:47           ` Lars-Dominik Braun
  2021-02-05 10:40         ` Hartmut Goebel
  2021-05-17  6:24         ` Lars-Dominik Braun
  3 siblings, 1 reply; 23+ messages in thread
From: Ryan Prior @ 2021-01-24 20:54 UTC (permalink / raw)
  To: Tanguy Le Carrour, Lars-Dominik Braun
  Cc: Development of GNU Guix and the GNU System distribution

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

On January 23, 2021, Lars-Dominik Braun <lars@6xq.net> wrote:\r
> [...] Remove pip and\r
> setuptools from python (saves almost 20MiB from the closure and avoids\r
> weird conflicts between python’s setuptools and python-setuptools) and\r
> turn them into (almost) ordinary packages. \r
\r
I think if we do that then Python will need a treatment similar to GCC,\r
where we don't expose the package and instead offer a compound package\r
(could be called "python-toolchain" or just "python") which includes pip\r
and setuptools. The last decades of python packaging have trained people\r
that when you install python you get pip and setuptools as well, I think\r
we should not try to be too clever and violate that assumption.\r
\r
Also, for what it's worth, we already have python-minimal which doesn't\r
have pip, and it's only  \r

[-- Attachment #2: Type: text/html, Size: 3156 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2021-01-24 20:54         ` Ryan Prior
@ 2021-01-25 11:47           ` Lars-Dominik Braun
  2021-01-25 16:57             ` Ryan Prior
  0 siblings, 1 reply; 23+ messages in thread
From: Lars-Dominik Braun @ 2021-01-25 11:47 UTC (permalink / raw)
  To: Ryan Prior; +Cc: Development of GNU Guix and the GNU System distribution

Hi Ryan,

> I think if we do that then Python will need a treatment similar to GCC,
> where we don't expose the package and instead offer a compound package
> (could be called "python-toolchain" or just "python") which includes pip
> and setuptools. The last decades of python packaging have trained people
> that when you install python you get pip and setuptools as well, I think
> we should not try to be too clever and violate that assumption.
this change is actually more about moving forward and adding PEP 517
support to python-build-system. Being able to demote setuptools and pip
to ordinary packages is merely a side-effect, because they’re not
essential any more.

Your mail seems to be incomplete, it stopped after:
> Also, for what it's worth, we already have python-minimal which doesn't
> have pip, and it's only  

Cheers,
Lars



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2021-01-25 11:47           ` Lars-Dominik Braun
@ 2021-01-25 16:57             ` Ryan Prior
  0 siblings, 0 replies; 23+ messages in thread
From: Ryan Prior @ 2021-01-25 16:57 UTC (permalink / raw)
  To: Lars-Dominik Braun
  Cc: Development of GNU Guix and the GNU System distribution

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

\r
On January 25, 2021, Lars-Dominik Braun <lars@6xq.net> wrote:\r
> Being able to demote setuptools and pip\r
> to ordinary packages is merely a side-effect, because they’re not\r
> essential any more.\r
\r
I didn't read all of PEP 517, does it deprecate bundling pip with\r
Python? My understanding was that it just gives maintainers more options\r
and makes setuptools less of a de-facto standard. I'll read it more\r
thoroughly later and see if I missed some important info there.\r
\r
Anyhow, even if a PEP says so, people's expectations to be able to use\r
pip will not disappear suddenly. It's part of the expected interface to\r
Python & I imagine removing it has the potential to cause much\r
confusion.\r
\r
> Your mail seems to be incomplete, it stopped after:\r
> > Also, for what it's worth, we already have python-minimal which\r
> doesn't\r
> > have pip, and it's only\r
\r
Ah darn, I'd meant to write it's only a little bit smaller, and I'm\r
interested to see where we can slim down the Python closure but others\r
have managed to do so without cutting out pip & setuptools.\r
\r
All this being said, I'm not a huge fan of pip & setuptools, I like Guix\r
because it frees me from having to think so much about such things, so I\r
hope this doesn't come off as a defense of the tools themselves. I mean\r
to defend the many Python users who have been trained with a certain set\r
of expectations about the interfaces a Python package provides.\r

[-- Attachment #2: Type: text/html, Size: 3816 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2021-01-22  8:38     ` Tanguy LE CARROUR
  2021-01-23 12:34       ` Lars-Dominik Braun
@ 2021-01-26  7:21       ` Tanguy LE CARROUR
  2021-01-27  3:43         ` Maxim Cournoyer
  1 sibling, 1 reply; 23+ messages in thread
From: Tanguy LE CARROUR @ 2021-01-26  7:21 UTC (permalink / raw)
  To: Guix, Lars-Dominik Braun

Excerpts from Tanguy LE CARROUR's message of January 22, 2021 9:38 am:
> Excerpts from Tanguy LE CARROUR's message of January 6, 2021 4:32 pm:
>> Excerpts from Lars-Dominik Braun's message of January 5, 2021 11:25 am:
>>>> So, I've tried packaging `python-keyring` with those two…
>>>> 
>>>> `pep517` keeps on trying to download dependencies, which won't work.
>>>> 
>>>> `build` crashes with "ZIP does not support timestamps before 1980",
>>>> which, I guess is related to the fact that everything in the store is
>>>> timestamped to January 1st 1970.
>>> have you been looking into a python-build-system using `build`[1]? I’ve
>>> had the same issue with egg versions set to 0.0.0 and think in the long
>>> run moving to a PEP 517-style build is the way forward.
>> 
>> I agree! Unfortunately, I haven't had much time (so far) to work on it! :-(
>> 
>> I'll revive the thread as soon as I've made progress…
> 
> Done! :-)
> I've eventually succeeded in ("properly") packaging a software managed
> with Poetry. And I've learned quite a lot on the way!

Just for the sake of having it documented somewhere, here is the
relevant part of the `guix.scm` file:

```
(define-public nowty
  (package
    (name "nowty")
    (version (string-append %pyproject-version "+" %git-commit))
    (source (local-file %source-dir #:recursive? #t))
    (build-system python-build-system)
    (arguments
     `(#:phases
       (modify-phases %standard-phases
        (replace 'build
         (lambda* (#:key #:allow-other-keys)
           (substitute* "pyproject.toml"
            (((string-append "version = \"" ,%pyproject-version "\"" ))
             (string-append "version = \"" ,version "\"")))))
        (replace 'install
         (lambda* (#:key outputs #:allow-other-keys)
          (let ((out (assoc-ref outputs "out")))
           (invoke "python" "-m" "pip" "install"
                   "--no-dependencies" "--no-build-isolation" "--prefix" out "."))))
        (replace 'check
         (lambda* (#:key inputs outputs #:allow-other-keys)
          (add-installed-pythonpath inputs outputs)
          (invoke "python" "-m" "invoke" "test.unit"))))))
    (native-inputs
     `(("python-invoke" ,python-invoke-patched)
       ("python-mamba" ,python-mamba)
       ("python-poetry-core" ,python-poetry-core)
       ("python-robber" ,python-robber)
       ("python-termcolor" ,python-termcolor)))
    (propagated-inputs
     `(("python-mpd2" ,python-mpd2)
       ("python-typer" ,python-typer)))
    (synopsis "Music notification daemon for MPD")
    (description "A music notification daemon that monitors songs being played by MPD
and displays notifications with the song's details.")
    (home-page "http://projects.bioneland.org/nowty")
    (license license:gpl3+)))
```

-- 
Tanguy


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2021-01-26  7:21       ` Tanguy LE CARROUR
@ 2021-01-27  3:43         ` Maxim Cournoyer
  0 siblings, 0 replies; 23+ messages in thread
From: Maxim Cournoyer @ 2021-01-27  3:43 UTC (permalink / raw)
  To: Tanguy LE CARROUR; +Cc: Guix

Hello,

Tanguy LE CARROUR <tanguy@bioneland.org> writes:

> Excerpts from Tanguy LE CARROUR's message of January 22, 2021 9:38 am:
>> Excerpts from Tanguy LE CARROUR's message of January 6, 2021 4:32 pm:
>>> Excerpts from Lars-Dominik Braun's message of January 5, 2021 11:25 am:
>>>>> So, I've tried packaging `python-keyring` with those two…
>>>>> 
>>>>> `pep517` keeps on trying to download dependencies, which won't work.
>>>>> 
>>>>> `build` crashes with "ZIP does not support timestamps before 1980",
>>>>> which, I guess is related to the fact that everything in the store is
>>>>> timestamped to January 1st 1970.
>>>> have you been looking into a python-build-system using `build`[1]? I’ve
>>>> had the same issue with egg versions set to 0.0.0 and think in the long
>>>> run moving to a PEP 517-style build is the way forward.
>>> 
>>> I agree! Unfortunately, I haven't had much time (so far) to work on it! :-(
>>> 
>>> I'll revive the thread as soon as I've made progress…
>> 
>> Done! :-)
>> I've eventually succeeded in ("properly") packaging a software managed
>> with Poetry. And I've learned quite a lot on the way!
>
> Just for the sake of having it documented somewhere, here is the
> relevant part of the `guix.scm` file:
>
> ```
> (define-public nowty
>   (package
>     (name "nowty")
>     (version (string-append %pyproject-version "+" %git-commit))
>     (source (local-file %source-dir #:recursive? #t))
>     (build-system python-build-system)
>     (arguments
>      `(#:phases
>        (modify-phases %standard-phases
>         (replace 'build
>          (lambda* (#:key #:allow-other-keys)
>            (substitute* "pyproject.toml"
>             (((string-append "version = \"" ,%pyproject-version "\"" ))
>              (string-append "version = \"" ,version "\"")))))
>         (replace 'install
>          (lambda* (#:key outputs #:allow-other-keys)
>           (let ((out (assoc-ref outputs "out")))
>            (invoke "python" "-m" "pip" "install"
>                    "--no-dependencies" "--no-build-isolation" "--prefix" out "."))))
>         (replace 'check
>          (lambda* (#:key inputs outputs #:allow-other-keys)
>           (add-installed-pythonpath inputs outputs)
>           (invoke "python" "-m" "invoke" "test.unit"))))))
>     (native-inputs
>      `(("python-invoke" ,python-invoke-patched)
>        ("python-mamba" ,python-mamba)
>        ("python-poetry-core" ,python-poetry-core)
>        ("python-robber" ,python-robber)
>        ("python-termcolor" ,python-termcolor)))
>     (propagated-inputs
>      `(("python-mpd2" ,python-mpd2)
>        ("python-typer" ,python-typer)))
>     (synopsis "Music notification daemon for MPD")
>     (description "A music notification daemon that monitors songs being played by MPD
> and displays notifications with the song's details.")
>     (home-page "http://projects.bioneland.org/nowty")
>     (license license:gpl3+)))
> ```

As another PEP 517 package build example, you may want to look at
python-isort on core-updates (commit
812a2931de553d12c01b0a4d53d03613b09adaaf).  Here's the definition:

--8<---------------cut here---------------start------------->8---
(define-public python-isort
  (package
    (name "python-isort")
    (version "5.7.0")
    (source
     (origin
       (method git-fetch)
       (uri (git-reference
             ;; Tests pass only from the Github sources
             (url "https://github.com/timothycrosley/isort")
             (commit version)))
       (file-name (git-file-name name version))
       (modules '((guix build utils)))
       (snippet '(for-each delete-file (find-files "." "\\.whl$")))
       (sha256
        (base32
         "0phq4s911mjjdyr5h5siz93jnpkqb2qgphgcfk6axncgxr8i7vi1"))))
    (build-system python-build-system)
    (arguments
     `(#:phases
       (modify-phases %standard-phases
         ;; A foretaste of what our future python-build-system will need to
         ;; do.
         (replace 'build
           (lambda _
             (invoke "python" "-m" "build" "--wheel" "--no-isolation" ".")))
         (replace 'install
           (lambda* (#:key outputs #:allow-other-keys)
             (let ((out (assoc-ref outputs "out"))
                   (whl (car (find-files "dist" "\\.whl$"))))
               (invoke "pip" "--no-cache-dir" "--no-input"
                       "install" "--no-deps" "--prefix" out whl))))
         (add-after 'install 'install-example-plugins
           (lambda* (#:key outputs #:allow-other-keys)
             (let ((out (assoc-ref outputs "out")))
               ;; Patch to use the core poetry API.
               (substitute* '("example_isort_formatting_plugin/pyproject.toml"
                              "example_shared_isort_profile/pyproject.toml")
                 (("poetry>=0.12")
                  "poetry-core>=1.0.0")
                 (("poetry.masonry.api")
                  "poetry.core.masonry.api"))
               ;; Build the example plugins.
               (for-each (lambda (source-directory)
                           (invoke "python" "-m" "build" "--wheel"
                                   "--no-isolation" "--outdir=dist"
                                   source-directory))
                         '("example_isort_formatting_plugin"
                           "example_shared_isort_profile"))
               ;; Install them to temporary storage, for the test.
               (setenv "HOME" (getcwd))
               (let ((example-whls (find-files "dist" "^example.*\\.whl$")))
                 (apply invoke "pip" "--no-cache-dir" "--no-input"
                        "install"  "--user" "--no-deps" example-whls)))))
         (replace 'check
           (lambda* (#:key tests? inputs outputs #:allow-other-keys)
             (when tests?
               (let ((bin (string-append (assoc-ref outputs "out") "/bin")))
                 (setenv "PATH" (string-append (getenv "PATH") ":" bin)))
               (add-installed-pythonpath inputs outputs)
               (invoke "pytest" "-vv" "tests/unit/"
                       "--ignore=tests/unit/test_deprecated_finders.py")))))))
    (native-inputs
     `(("git" ,git-minimal)
       ("python-black" ,python-black)
       ("python-colorama" ,python-colorama)
       ("python-hypothesmith" ,python-hypothesmith)
       ("python-libcst" ,python-libcst-minimal)
       ("python-poetry-core" ,python-poetry-core)
       ("python-pylama" ,python-pylama)
       ("python-pypa-build" ,python-pypa-build)
       ("python-pytest-mock" ,python-pytest-mock)
       ("python-pytest" ,python-pytest)))
    (home-page "https://github.com/PyCQA/isort")
    (synopsis "Python utility/library to sort python imports")
    (description "@code{python-isort} is a python utility/library to sort
imports alphabetically, and automatically separated into sections.  It
provides a command line utility, a python library and plugins for various
editors.")
    (license license:expat)))
--8<---------------cut here---------------end--------------->8---

That's an ad-hoc solution pending an update to our Python build system
phases.

HTH!

Maxim


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2021-01-23 12:34       ` Lars-Dominik Braun
  2021-01-24 13:30         ` Tanguy LE CARROUR
  2021-01-24 20:54         ` Ryan Prior
@ 2021-02-05 10:40         ` Hartmut Goebel
  2021-05-17  6:24         ` Lars-Dominik Braun
  3 siblings, 0 replies; 23+ messages in thread
From: Hartmut Goebel @ 2021-02-05 10:40 UTC (permalink / raw)
  To: guix-devel

Am 23.01.21 um 13:34 schrieb Lars-Dominik Braun:
> Remove pip and
> setuptools from python (saves almost 20MiB from the closure

When doing to we need to be carefully. pip is expected to be available 
after installing "python". So when removing pip and setuptool, we would 
need some "python/bootstrap" package without pip and setuptools and some 
"python" package still including both.


-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2021-01-23 12:34       ` Lars-Dominik Braun
                           ` (2 preceding siblings ...)
  2021-02-05 10:40         ` Hartmut Goebel
@ 2021-05-17  6:24         ` Lars-Dominik Braun
  2021-06-06 16:44           ` Tanguy LE CARROUR
  3 siblings, 1 reply; 23+ messages in thread
From: Lars-Dominik Braun @ 2021-05-17  6:24 UTC (permalink / raw)
  To: guix-devel

Hi everyone,

just a quick reminder that an updated version (includes
python-toolchain) of this proposal is still looking for a code review or
further discussion. So if you feel confident about touching
python-build-system, please have a look at
https://issues.guix.gnu.org/46848#1

I’d be nice to get this into core-updates before the next merge.
Otherwise we’ll have to keep adding workarounds (see for example
python-testpath in master) to Python packages not using setuptools as
their build system.

Cheers,
Lars



^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2021-05-17  6:24         ` Lars-Dominik Braun
@ 2021-06-06 16:44           ` Tanguy LE CARROUR
  2021-06-06 19:44             ` Lars-Dominik Braun
  0 siblings, 1 reply; 23+ messages in thread
From: Tanguy LE CARROUR @ 2021-06-06 16:44 UTC (permalink / raw)
  To: guix-devel, Lars-Dominik Braun

Hi Lars,


Excerpts from Lars-Dominik Braun's message of May 17, 2021 8:24 am:
> just a quick reminder that an updated version (includes
> python-toolchain) of this proposal is still looking for a code review or
> further discussion. So if you feel confident about touching
> python-build-system, please have a look at
> https://issues.guix.gnu.org/46848#1
> 
> I’d be nice to get this into core-updates before the next merge.
> Otherwise we’ll have to keep adding workarounds (see for example
> python-testpath in master) to Python packages not using setuptools as
> their build system.

Sorry if I'm (very) late, but apprently this hasn't made it to master
yet, so… What the status? Do you still need a willing-but-maybe-not-qualified
person to review or discuss your patch?

Regards,

-- 
Tanguy


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Questions regarding Python packaging
  2021-06-06 16:44           ` Tanguy LE CARROUR
@ 2021-06-06 19:44             ` Lars-Dominik Braun
  0 siblings, 0 replies; 23+ messages in thread
From: Lars-Dominik Braun @ 2021-06-06 19:44 UTC (permalink / raw)
  To: Tanguy LE CARROUR; +Cc: guix-devel, 46848

Hi Tanguy,

(cross-posting this to the issue itself too)

> Sorry if I'm (very) late, but apprently this hasn't made it to master
> yet, so… What the status? Do you still need a willing-but-maybe-not-qualified
> person to review or discuss your patch?
the patch set works, I can build many Python packages, although some
require changes. Still, multiple things need to be done before merging
is possible imo:

1) Validate the general idea of using pypa-build is viable and
   sustainable in the long run – ideally through review by someone else
   than me. We can’t touch python-build-system every week to solve
   structural issues, so it needs to be bullet-proof.
2) Figure out how to run testing code. Currently python-build-system
   just picks pytest, if available – not sure this is the best option we
   have. How do we deal with other test systems? How do we pass options?
3) Determine the fate of Python 2, which is probably broken through this
   patch set. Shall we remove it entirely? Is it worth to keep support?
4) Iron out minor details like including pip in the python package or
   create a new python-toolchain package? What do we include in that
   meta-package? pip? virtualenv? …?
5) Fix my awkward Scheme code, especially regarding unpacking of the
   built wheels. Should we be using Python’s unzip module or can be
   assumed unzip is available in the build environment? (Should we add
   it?)

I’m by no means a Python packaging expert, so any help would be
appreciated, even if it’s just a question or thumbs-up/thumbs-down on my
ideas.

Cheers,
Lars



^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2021-06-06 19:45 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-08 14:27 Questions regarding Python packaging Tanguy Le Carrour
2020-11-08 17:05 ` Leo Famulari
2020-11-10  8:35   ` Tanguy Le Carrour
2020-11-08 20:43 ` Michael Rohleder
2020-11-10  8:30   ` Tanguy Le Carrour
2020-11-09 16:54 ` Hartmut Goebel
2020-11-10  8:47   ` Tanguy Le Carrour
2020-11-10  8:53     ` Hartmut Goebel
2021-01-05 10:25 ` Lars-Dominik Braun
2021-01-06 15:32   ` Tanguy LE CARROUR
2021-01-22  8:38     ` Tanguy LE CARROUR
2021-01-23 12:34       ` Lars-Dominik Braun
2021-01-24 13:30         ` Tanguy LE CARROUR
2021-01-24 20:54         ` Ryan Prior
2021-01-25 11:47           ` Lars-Dominik Braun
2021-01-25 16:57             ` Ryan Prior
2021-02-05 10:40         ` Hartmut Goebel
2021-05-17  6:24         ` Lars-Dominik Braun
2021-06-06 16:44           ` Tanguy LE CARROUR
2021-06-06 19:44             ` Lars-Dominik Braun
2021-01-26  7:21       ` Tanguy LE CARROUR
2021-01-27  3:43         ` Maxim Cournoyer
2021-01-06 15:37   ` Tanguy LE CARROUR

unofficial mirror of guix-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-devel/0 guix-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-devel guix-devel/ https://yhetil.org/guix-devel \
		guix-devel@gnu.org
	public-inbox-index guix-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.devel
	nntp://news.gmane.io/gmane.comp.gnu.guix.devel


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git