1.6.0 is out and needs updating shim packages for testing. My suggestion would be to last rite this crap instead.
(In reply to Michał Górny from comment #0) > 1.6.0 is out and needs updating shim packages for testing. My suggestion > would be to last rite this crap instead. It will be better to just keep the tests online. In 0f9dc502a7920152f07009d8926a170625be862b you made the changes to create this shim but for me it was fine to rely on network for testing this package.
You have no ethical concerns with every test run involving a few gigs of network traffic on production pypi.org instance to repeatedly fetch the same files? Not to mention it makes them very slow and unreliable.
Well pipx is part of pypa which is kinda the authority. So if they do not care about their consumption on pypi.org, I do not care neither. But anyway, I looked how to generate this shim package and it does not seem too complicated using https://pipx.pypa.io/stable/contributing/#running-unit-tests-offline
I uploaded https://dev.gentoo.org/~cedk/dist/pipx-1.6.0-test-shim.tar.xz which pass the tests. But I'm little bit concern that it contains arch specific wheels. So it works for now because there is only amd64 but it will be more complicated if another arch is added.
That's why I've put tremendous effort into stripping it down to just the bare necessary files, made them ABI agnostic and recompressed the wheels with "store" method. It's not that simple.
This looks complicated if you do not provide instructions on how to do that. Now I said it will be complicated to add more arch only because you need access to these arch to use their provided script. But indeed one can just download the corresponding wheel from pypi.org.
You do realize that most of the time, wheels are provided for up to the two most commonly used platforms?
(In reply to Michał Górny from comment #7) > You do realize that most of the time, wheels are provided for up to the two > most commonly used platforms? I do not understand what you want to say.
I'm saying that your approach won't work outside amd64/arm64. Nevermind, I'll just do it myself.
(In reply to Michał Górny from comment #9) > I'm saying that your approach won't work outside amd64/arm64. > > Nevermind, I'll just do it myself. If you do not want to explain than do not complaint about this packages for testing. If you keep the generation of this archive secrets, I will no more be able to be the maintainer of this package.
It's not a secret. As I've said, I've done it by hand as a dirty proof-of-concept and I haven't written down anything. We have to *start over* and do it properly.
Well I see no problem with my simple way which uses the tools from the project. If new arch are added, the project command will need to be run on each arch to collect all the dependencies. Not including binary wheels may require more dependencies for the test as installing the source wheel would require compilation and maybe external libraries.
(In reply to Cédric Krier from comment #12) > Well I see no problem with my simple way which uses the tools from the > project. > If new arch are added, the project command will need to be run on each arch > to collect all the dependencies. And how is it going to do that when there are *no* wheels for a given arch? Also, I do hope you've verified that we can actually redistribute all these wheels.
(In reply to Michał Górny from comment #13) > (In reply to Cédric Krier from comment #12) > > Well I see no problem with my simple way which uses the tools from the > > project. > > If new arch are added, the project command will need to be run on each arch > > to collect all the dependencies. > > And how is it going to do that when there are *no* wheels for a given arch? I guess the tests will pick up the source base version. > Also, I do hope you've verified that we can actually redistribute all these > wheels. Then I prefer to go back to the initial design and use the network version of the tests.
Then you're going to have unethical, slow and flaky tests. Believe me, I didn't waste all that time for theoretical problems. I did it because it was simply impossible for me to do a full test run without at least one implementation randomly failing.
commit 95fe9c883a26ba9aa92ada4aea62b754b429742a Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2024-06-04 17:37:44 +0200 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-06-04 17:40:05 +0200 dev-python/pipx: Bump to 1.6.0 Signed-off-by: Michał Górny <mgorny@gentoo.org>
