[pytest-dev] Fw: Vendoring pluggy with pytest

[Thomas Moschny]

Beginn der weitergeleiteten Nachricht:

Datum: Sun, 6 Sep 2015 08:18:17 +0200
Von: Thomas Moschny <thomas.moschny at gmx.de>
An: Petr Viktorin <encukou at gmail.com>
Cc: Florian Bruhin <me at the-compiler.org>, "pytest-dev at python.org"
<pytest-dev at python.org>, pytest-owner at fedoraproject.org
Betreff: Re: [pytest-dev] Vendoring pluggy with pytest


Hi,

sorry for not answering earlier. What Petr says is absolutely right.
Fedora packaging guidelines in general forbid bundling:

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

For example, we are striving for unbundling apipkg in pylib and
execnet, see
  https://bugzilla.redhat.com/show_bug.cgi?id=790163 and
  https://bugzilla.redhat.com/show_bug.cgi?id=790165
respectively, and the corresponding upstream bugs
  https://bitbucket.org/pytest-dev/py/issues/31 and 
  https://bitbucket.org/hpk42/execnet/issues/13

So, as per guidelines, we'd have to unbundle pluggy for the pytest RPM
package as well.

Exceptions are possible under certain circumstances, but need
a blessing from the Fedora Packaging Committee - but this creates some
bureaucratic overhead, so as a packager, I am not really keen on going
through that, and needs to be justified.

One of the reasons for granting an exception can be: "Needing
unreleased features" - however, in the scenario we discuss here, that
would apply to *other* projects using a more recent snapshot of pluggy,
not pytest, so they'd have to (ask for an exception and) bundle that
snapshot of pluggy. For pytest we'd still have to unbundle it.

Another option could be to package more than one version of pluggy.
This is in general possible, but of course has other disadvantages, and
also creates a lot of overhead.

So, to summarize things from a distribution point of view:
Please don't bundle.

Regards,
Thomas


Am Sat, 5 Sep 2015 22:20:49 +0200
schrieb Petr Viktorin <encukou at gmail.com>:

> On Wed, Aug 26, 2015 at 10:43 AM, Florian Bruhin
> <me at the-compiler.org> wrote:
> > Hi!
> >
> > I'm part of the pytest-dev team, the developers of the pytest[1]
> > test runner. I'm writing to you because I'd like to have some
> > opinions on the following PR/issue about vendoring pluggy into
> > pytest:
> >
> > https://github.com/pytest-dev/pytest/issues/944
> > https://github.com/pytest-dev/pytest/pull/959
> >
> > The common logic behind the plugin API of pytest recently got split
> > into a separate library, pluggy[2].
> >
> > However, the public API of pluggy might still change in the near
> > future - which means pytest would need to require a specific version
> > of pluggy to be sure there's no breakage.
> >
> > Normally, this wouldn't be an issue - but as a test runner, I
> > believe we're in a bit of a special position: Users should still be
> > able to use pytest to test their projects, even if their projects
> > use a more recent version of pluggy - or they use other projects
> > which might use pluggy in the future, like devpi or tox.
> >
> > Because of this, since it's a very small library, and because the
> > code originated from pytest, I wonder what distribution's views are
> > on bundling the library for pytest 2.8 until things are expected to
> > be a bit more stable.
> >
> > What do you think?
> 
> Hello,
> I haven't seen a reply here, but I can say what's customary in Fedora.
> 
> Per our packaging guidelines, we would need to unbundle pluggy. So, if
> you install pytest from a RPM, you'd get the matching version of
> pluggy from a separate RPM. These will be synchronized via the package
> manager, so that you can't end up with incompatible versions there.
> Any system package that needs pytest will need to use the system
> versions of pytest and pluggy -- so devpi or tox packagers would need
> to coordinate with the pytest/pluggy packagers, and use versions that
> all work together. (Making sure things work together is the job of a
> distribution, after all.)
> 
> If a Fedora user installs pytest from pypi into a virtualenv, they
> would get your bundled copy. Virtualenvs are isolated from the system,
> so I see no problems there.
>