* Bruno Oliveira <[email protected]> [2015-08-25 11:58:08 +0000]: > > * Floris Bruynooghe <[email protected]> [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.
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 <[email protected]> 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: https://github.com/pytest-dev/pytest/issues/944#issuecomment-134568839 Florian -- http://www.the-compiler.org | [email protected] (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
pgpVSZxk8s7vD.pgp
Description: PGP signature
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
