Re: Rubygem package smoke testing [was: Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)]

Dne 17. 06. 21 v 13:26 Ewoud Kohl van Wijngaarden napsal(a): On Wed, Jun 16, 2021 at 02:21:18PM +0200, Vít Ondruch wrote: Dne 16. 06. 21 v 13:36 Ewoud Kohl van Wijngaarden napsal(a): On Wed, Jun 16, 2021 at 01:17:31PM +0200, Vít Ondruch wrote: Dne 15. 06. 21 v 19:34 Ewoud Kohl van

Re: Rubygem package smoke testing [was: Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)]

On Wed, Jun 16, 2021 at 02:21:18PM +0200, Vít Ondruch wrote: Dne 16. 06. 21 v 13:36 Ewoud Kohl van Wijngaarden napsal(a): On Wed, Jun 16, 2021 at 01:17:31PM +0200, Vít Ondruch wrote: Dne 15. 06. 21 v 19:34 Ewoud Kohl van Wijngaarden napsal(a): On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro

Re: Rubygem package smoke testing [was: Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)]

Dne 16. 06. 21 v 13:36 Ewoud Kohl van Wijngaarden napsal(a): On Wed, Jun 16, 2021 at 01:17:31PM +0200, Vít Ondruch wrote: Dne 15. 06. 21 v 19:34 Ewoud Kohl van Wijngaarden napsal(a): On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro Hrončok wrote: On 15. 06. 21 13:46, Vitaly Zaitsev via devel

Rubygem package smoke testing [was: Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)]

On Wed, Jun 16, 2021 at 01:17:31PM +0200, Vít Ondruch wrote: Dne 15. 06. 21 v 19:34 Ewoud Kohl van Wijngaarden napsal(a): On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro Hrončok wrote: On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote: If that is not possible with reasonable effort, at

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

Dne 15. 06. 21 v 19:34 Ewoud Kohl van Wijngaarden napsal(a): On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro Hrončok wrote: On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote: If that is not possible with reasonable effort, at least a basic smoke test (such as importing the packaged module)

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 16. 06. 21 10:10, Alfredo Moralejo Alonso wrote: On Tue, Jun 15, 2021 at 7:41 PM Miro Hrončok > wrote: On 15. 06. 21 19:34, Ewoud Kohl van Wijngaarden wrote: > And for those of us who also maintain packages for EL7/8, what's the > availability of

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Tue, Jun 15, 2021 at 7:41 PM Miro Hrončok wrote: > On 15. 06. 21 19:34, Ewoud Kohl van Wijngaarden wrote: > > And for those of us who also maintain packages for EL7/8, what's the > > availability of these macros? > > Whenever technically possible, we add our new Python macros to EPEL 7+. >

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Tue, Jun 15, 2021 at 12:50:03PM +0200, Petr Viktorin wrote: On 15. 06. 21 2:11, Neal Gompa wrote: It's not terribly different from how organizations may have private Python package indexes that may use whatever names they want for Python software they build and release. I agree, in fact, I

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 15. 06. 21 19:34, Ewoud Kohl van Wijngaarden wrote: And for those of us who also maintain packages for EL7/8, what's the availability of these macros? Whenever technically possible, we add our new Python macros to EPEL 7+. Sometimes, we even backport them to plain RHEL 8+. This can (and

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro Hrončok wrote: On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote: If that is not possible with reasonable effort, at least a basic smoke test (such as importing the packaged module) *MUST* be run in `+%check+`. A simple scriplet should be

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

Petr Viktorin writes: > On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote: >> On 14.06.2021 15:32, Ben Cotton wrote: >>> Running upstream tests is mandatory. >> >> What about tests that require network access? > > > Thanks for this and all the other concerns about mandatory tests! > I updated

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 15. 06. 21 13:48, Neal Gompa wrote: On Tue, Jun 15, 2021 at 6:50 AM Petr Viktorin wrote: Hi Neal, We had this conversation in the past (and you can see it in the change). I don't think I can convince you, but I'll reiterate since it's new for devel@. Unlike the "mandatory tests" issue

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 21:00, Miro Hrončok wrote: I tentatively agree with the idea of requiring an “import foo.bar” smoke test in cases where the upstream tests cannot be used, especially since pyproject-rpm-macros with %pyproject_buildrequires makes it much easier to add runtime dependencies as

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote: If that is not possible with reasonable effort, at least a basic smoke test (such as importing the packaged module) *MUST* be run in `+%check+`. A simple scriplet should be introduced I think: %check %do_import_test Already on it:

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Tue, Jun 15, 2021 at 6:50 AM Petr Viktorin wrote: > > Hi Neal, > We had this conversation in the past (and you can see it in the change). > I don't think I can convince you, but I'll reiterate since it's new for > devel@. > > Unlike the "mandatory tests" issue elsewhere in this thread, using

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 15.06.2021 13:33, Petr Viktorin wrote: If a test suite exists upstream, it *SHOULD* be run in the `+%check+` section. LGTM now. Many thanks. If that is not possible with reasonable effort, at least a basic smoke test (such as importing the packaged module) *MUST* be run in `+%check+`. A

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 15. 06. 21 13:32, Alexander Bokovoy wrote: On ti, 15 kesä 2021, Petr Viktorin wrote: On 14. 06. 21 20:09, Alexander Bokovoy wrote: On ma, 14 kesä 2021, Ben Cotton wrote: [...] PyPI Parity Machine-readable metadata (''distribution'' names in dist-info directories on disk and the

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote: On 14.06.2021 15:32, Ben Cotton wrote: Running upstream tests is mandatory. What about tests that require network access? Thanks for this and all the other concerns about mandatory tests! I updated the proposal to mane them not

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On ti, 15 kesä 2021, Petr Viktorin wrote: On 14. 06. 21 20:09, Alexander Bokovoy wrote: On ma, 14 kesä 2021, Ben Cotton wrote: [...] PyPI Parity Machine-readable metadata (''distribution'' names in dist-info directories on disk and the corresponding python3.Xdist(foo) RPM provides)

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14.06.2021 22:33, Dan Čermák wrote: I would then suggest to change the wording from "Running upstream tests is mandatory." to "Upstream tests SHOULD be run unless there are compelling reasons. In that case basic smoke tests MUST be added to %check". +1 for this. -- Sincerely, Vitaly

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 15.06.2021 10:14, Vít Ondruch wrote: I think that "use your bests judgement" still applies. So whatever is in guidelines should be respected, but sometimes there needs to be exceptions. The word "MUST" should be replaced by "SHOULD" then. If upstream tests works fine, I always enable them,

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

I'll address the larger "mandatory tests" issue later; thanks for all your concerns! This point deserves a reply on its own: On 14. 06. 21 19:35, Benjamin Beasley wrote: [...] It’s also not clear to me why the Python guidelines should be so much stricter than the overall Fedora guidelines

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 20:09, Alexander Bokovoy wrote: On ma, 14 kesä 2021, Ben Cotton wrote: [...] PyPI Parity Machine-readable metadata (''distribution'' names in dist-info directories on disk and the corresponding python3.Xdist(foo) RPM provides) will match the Python Package Index

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

Hi Neal, We had this conversation in the past (and you can see it in the change). I don't think I can convince you, but I'll reiterate since it's new for devel@. Unlike the "mandatory tests" issue elsewhere in this thread, using the PyPI namespace is the main point of the change. I can't

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 17:39, Richard W.M. Jones wrote: Questions, questions ... These new guidelines seem to be fine for pure Python packages, but I'm maintaining a couple of packages where Python bindings are built as subpackages of existing C libraries: https://src.fedoraproject.org/rpms/libnbd

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

Dne 14. 06. 21 v 19:30 Vitaly Zaitsev via devel napsal(a): On 14.06.2021 19:16, Miro Hrončok wrote: That is exactly the thing we need to avoid. Python packages without tests always cause trouble when we measure impact of our changes. E.g. when we continuously rebuild packages with the next

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 6/14/21 6:07 PM, Neal Gompa wrote: That only worked because public was default, not private. That's not how it works for Fedora packages at all. You're much more experienced in this area than I am, so I'm inclined to think that you're right and I'm missing something. The guidelines do

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Mon, Jun 14, 2021 at 8:35 PM Gordon Messmer wrote: > > On 6/14/21 5:11 PM, Neal Gompa wrote: > > On Mon, Jun 14, 2021 at 8:02 PM Gordon Messmer > > wrote: > >> https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 > > It's not terribly different from how organizations may have

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 6/14/21 5:11 PM, Neal Gompa wrote: On Mon, Jun 14, 2021 at 8:02 PM Gordon Messmer wrote: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 It's not terribly different from how organizations may have private Python package indexes that may use whatever names they want for

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Mon, Jun 14, 2021 at 8:02 PM Gordon Messmer wrote: > > On 6/14/21 1:53 PM, Neal Gompa wrote: > > This is completely unreasonable. The dist-info/egg-info data of a > > Python module is for generating dependencies, not for forcing people > > to deal with PyPI. > > > I don't think we can

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 6/14/21 1:53 PM, Neal Gompa wrote: This is completely unreasonable. The dist-info/egg-info data of a Python module is for generating dependencies, not for forcing people to deal with PyPI. I don't think we can reasonably separate the two.

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Mon, Jun 14, 2021 at 3:05 PM Miro Hrončok wrote: > > On 14. 06. 21 20:09, Alexander Bokovoy wrote: > >> PyPI Parity > >> > >> Machine-readable metadata (''distribution'' names in > >> dist-info directories on disk and the corresponding > >> python3.Xdist(foo) RPM provides) will match

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

Miro Hrončok writes: > On 14. 06. 21 19:35, Benjamin Beasley wrote: >> I’m still in favor of running every test that is even vaguely practical in >> %check, but upstream Python packaging practices are wildly diverse >> (arguably, a mess) and it seems like a strongly worded SHOULD with a >>

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 20:09, Alexander Bokovoy wrote: PyPI Parity Machine-readable metadata (''distribution'' names in dist-info directories on disk and the corresponding python3.Xdist(foo) RPM provides) will match the Python Package Index (PyPI). This solves a ''namespace'' issue. Python

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 20:28, Ben Beasley wrote: On Mon, Jun 14, 2021, at 2:07 PM, Miro Hrončok wrote: On 14. 06. 21 19:35, Benjamin Beasley wrote: However I think we should at least strictly require a smoke test (such as %python3 -c "import foo, foo.bar") in such cases, for reasons described below...

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Mon, Jun 14, 2021, at 2:07 PM, Miro Hrončok wrote: > On 14. 06. 21 19:35, Benjamin Beasley wrote: > However I think we should at least strictly require a smoke test (such as > %python3 -c "import foo, foo.bar") in such cases, for reasons described > below... > […] > > It’s also not clear to

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On ma, 14 kesä 2021, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/PythonPackagingGuidelines202x == Summary == The Python Packaging guidelines will be rewritten, with the major changes being '''PyPI parity''' and usage of '''upstream metadata'''. A new set of macros,

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 19:35, Benjamin Beasley wrote: I’m still in favor of running every test that is even vaguely practical in %check, but upstream Python packaging practices are wildly diverse (arguably, a mess) and it seems like a strongly worded SHOULD with a fallback of “trust the packager”

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On ma, 14 kesä 2021, Neal Gompa wrote: On Mon, Jun 14, 2021 at 11:57 AM Miro Hrončok wrote: On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote: > On 14.06.2021 15:32, Ben Cotton wrote: >> Running upstream tests is mandatory. > > What about tests that require network access? From the

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

I agree that running the tests wherever practical is the best practice. I do put my time where my mouth is—I maintain 17 packages that now use the pyproject-rpm-macros, and you’ll find that in general I’ve added a lot of %check sections to packages that were previously lacking them. However,

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14.06.2021 19:16, Miro Hrončok wrote: That is exactly the thing we need to avoid. Python packages without tests always cause trouble when we measure impact of our changes. E.g. when we continuously rebuild packages with the next Python release, pure Python packages with incompatibilities

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 18:32, Vitaly Zaitsev via devel wrote: On 14.06.2021 17:56, Miro Hrončok wrote: Assuming that *all the tests* require network access, you should run them on Fedora CI instead. And if I don't want to patch tests in downstream or not interested in runing tests at all? For

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 18:35, Neal Gompa wrote: On Mon, Jun 14, 2021 at 11:57 AM Miro Hrončok wrote: On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote: On 14.06.2021 15:32, Ben Cotton wrote: Running upstream tests is mandatory. What about tests that require network access? From the proposed

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On Mon, Jun 14, 2021 at 11:57 AM Miro Hrončok wrote: > > On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote: > > On 14.06.2021 15:32, Ben Cotton wrote: > >> Running upstream tests is mandatory. > > > > What about tests that require network access? > > From the proposed guidelines: > > > If a

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14.06.2021 17:56, Miro Hrončok wrote: Assuming that *all the tests* require network access, you should run them on Fedora CI instead. And if I don't want to patch tests in downstream or not interested in runing tests at all? For example my package wloc[1] has upstream tests, but they

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14. 06. 21 17:52, Vitaly Zaitsev via devel wrote: On 14.06.2021 15:32, Ben Cotton wrote: Running upstream tests is mandatory. What about tests that require network access? From the proposed guidelines: If a test suite exists upstream, it MUST be run in the %check section and/or in

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

On 14.06.2021 15:32, Ben Cotton wrote: Running upstream tests is mandatory. What about tests that require network access? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

Questions, questions ... These new guidelines seem to be fine for pure Python packages, but I'm maintaining a couple of packages where Python bindings are built as subpackages of existing C libraries: https://src.fedoraproject.org/rpms/libnbd https://src.fedoraproject.org/rpms/libguestfs [Yes