me at the-compiler.org
Tue Aug 25 14:26:39 CEST 2015
* Bruno Oliveira <nicoddemus at gmail.com> [2015-08-25 11:58:08 +0000]:
> > * 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,
> 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.
That's how I handled something similar in my project, and it did work
fine (I later then got rid of that 3rdparty requirement).
> > 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.
I answered on the issue:
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 --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the pytest-dev