Lars-Dominik Braun skriver: > Hi Marius, > >> Can you elaborate on the name clash issue? > the problem seems to be that most packages do not put the source code > into a subdirectory in the sdist. I.e. package foobar will have a foobar/ > directory, instead of src/foobar. Thus Python tries to load the module > foobar.barbaz from that directory, instead of the store. Thus it’ll > also look there for C extensions and fail. I don’t know why it does > that, even when *not* using `python -m` – according to the documentation > it should not. If anyone has any pointers I’d like to have a look again. Perhaps it could be worked around by building in a separate directory, i.e. ./build/lib, like setuptools does? And ensure that the original source directory does not end up on {,GUIX_}PYTHONPATH. (I don't really understand the problem, just throwing ideas around.) >> Unfortunately we need Python 2 for some time still. It is used to >> bootstrap old versions of GHC, Node, and probably other things. > But as far as I see these specific examples do not use > python-build-system. Only if some package using `#:python python-2` is > required during bootstrapping, then we’d need a way to support Python > 2, right? Right. If we don't need any Python 2 modules it should be fine to remove support from the build system. >> Do you think it is feasible to provide this as a new build system, say >> pep517-build-system, during a transitional period? Then we can a) start >> using it right away for the increasing amount of packages that lack a >> setup.py; and b) flesh out most bugs before eventually merging it back >> (possibly piecemeal) into python-build-system. > Actually, I think that’s a good idea. I tried, but I cannot fix all > packages broken by this change on my own, so smoothing the transition > could help and – as you said – we could catch bugs early on. > > I could prepare a patch, if there is interest in this path. It would lower the bar significantly for testing and contributing, so I would appreciate it. :-) >> * I also think trying "python setup.py test" is unnecessary. > It still works quite often, although its usefulness will decrease in > the future I guess. Another problem I see is that this command will not > fail if there are no tests. > >> * It would be nice to support the "no tests" case without having to add >> explicit #:tests? everywhere. Perhaps along the lines of... > My idea was to force packagers to make and explain this decision > explicitly. If you don’t run tests, you have to add `#:tests? #f` > and leave a comment why they are disabled. I do see this could become > a hassle with packages that simply don’t have any tests. But my hope > is that it increases package quality. My main concern is end-user experience when they just want to get some random library working on their local channel. But it's arguably something that can be solved on the importer level and not a strong opinion. Thinking about importers, perhaps they could start emitting git origins when possible, as there is a trend to strip tests before uploading to PyPI. >> (_ (apply invoke `("python" "-m" "unittest" ,@test-flags)))))) > If I remember correctly I tried this and it did not work for some > reason. I’ll have a look again. Eh, it should be (apply invoke "python" "-m" "unittest" test-flags), but you probably got that. :-P Thanks!