[pytest-dev] Releases

[Bruno Oliveira]

> * Floris Bruynooghe <flub at devork.be> [2015-08-25 09:45:31 +0100]:
> This on the other hand is more of a blocker.  I think what we need is
> some code in setup.py which automatically fetches the required pluggy
> version from pypi and vendors it when  making sdists and wheels.

Any reason to pinpoint that at release time only? I think it is desirable
to be able to pinpoint this during development as well.

As I understand it, vendoring means that we will have a copy of pluggy's
code into pytest under a different package name (say,
"_pytest.vendor.pluggy").

How about:

* Create a script which fetches the latest pluggy version, and installs it
into `_pytest.vendor.pluggy`;
* Add `_pytest.vendor.pluggy` to version control
* Update all references in pytest from `pluggy` to `_pytest.vendor.pluggy`;
* Remove the dependency from `setup.py`;

This way, we have total control on which version of pluggy we are using,
even during development, so it won't bring any surprises when merging PRs,
or differences between boxes. Also, upgrading to a new pluggy version is
just a matter of running the script and opening up a PR. :)

If you guys agree with this, I can work on it no problem.

> Florian Bruhin <me at the-compiler.org> wrote:
> What's the motivation to vendor pluggy rather than depending on it and letting
packages distribute it?

(I somehow missed the issue, I'm posting my comment below in there as well)

I think the reason is that it is very immature at this point: pluggy is at
0.3.0 now, but 0.4.0 might be backwards incompatible and would break all
pytest installations out there, and it isn't desirable to generate a new
pytest release just to comply with the changes in the new pluggy version.
One might pinpoint pluggy to a specific version in pytest, but I think it
is desirable to be able to create new features (possibly backward
incompatible ones) when working on another project which uses pluggy (devpi
for example), and that would pose a problem for users which use both
projects in the same environment, as both would have to be pinpointed to
incompatible versions.

Cheers,
Bruno.

On Tue, Aug 25, 2015 at 7:10 AM Florian Bruhin <me at the-compiler.org> wrote:

> * Floris Bruynooghe <flub at devork.be> [2015-08-25 09:45:31 +0100]:
> > Hello,
> >
> > On 9 August 2015 at 23:45, Bruno Oliveira <nicoddemus at gmail.com> wrote:
> > > Hi,
> > >
> > > I also think we should release 2.8 directly.
> >
> > Yes, a release which supports python 3.5 would be nice.  AFAIK we
> > could just release 2.7.3 without any work so if someone wants to
> > release that I think you should just do it.
>
> The Python 3.5 PR[1] was merged to master - it'd need to be backported
> to the pytest-2.7 branch first, right?
>
> [1] https://github.com/pytest-dev/pytest/pull/801
>
> > > There are a couple of issues/PRs that should go into 2.8, IMO:
> > >
> > > - Merge pytest-cache into core
> > > (https://github.com/pytest-dev/pytest/pull/828); I think Ronny is
> working on
> > > this;
> > > - Release pytest-xdist 1.13, so we can merge "non-zero exit code if no
> tests
> > > are collected" (https://github.com/pytest-dev/pytest/pull/817); I
> think
> > > Ronny is about to release 1.13;
> > >
> > > Actually, merge all PRs that are pending would be a good target, as
> they all
> > > seem like good additions to a new major release.
> >
> > These are nice to have, but not strictly needed.
>
> Most of them are merged in the meantime:
> https://github.com/pytest-dev/pytest/pulls
>
> There are only 4 open:
>
> - https://github.com/pytest-dev/pytest/pull/908 by Elizaveta239
>   Apply indirect=True on particular argnames
>
>   It seems work is going on to get it merged.
>
> - https://github.com/pytest-dev/pytest/pull/878 by ronny
>   reencode non-ascii python2 assertion reprs
>
>   Apparently that's actually a bug in pylib - should this still be
>   merged to have a workaround until the real bug is fixed, or should
>   this be abandoned?
>
> - https://github.com/pytest-dev/pytest/pull/831 by ronny
>   stop running yield test setupstate at collection time
>
>   I'm not sure what the state of this is - seems like it's waiting for
>   review?
>
> - https://github.com/pytest-dev/pytest/pull/828 by ronny
>   merge the pytest-cache plugin into core
>
>   I think ronny wanted to finish this somewhen soon.
>
>
> > > I think Holger also said before that he would like to vendor pluggy
> into
> > > pytest before releasing 2.8 thought. Is there anything here that we
> can do
> > > to help?
> >
> > This on the other hand is more of a blocker.  I think what we need is
> > some code in setup.py which automatically fetches the required pluggy
> > version from pypi and vendors it when  making sdists and wheels.  At
> > least while pluggy versions are < 1.0.  Once that's done we should be
> > able to release 2.8 without any problems.
>
> What's the motivation to vendor pluggy rather than depending on it and
> letting packages distribute it?
>
> I also opened an issue for that recently:
>
> https://github.com/pytest-dev/pytest/issues/944
>
> Florian
>
> --
> http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
>    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>          I love long mails! | http://email.is-not-s.ms/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150825/a337f089/attachment.html>