Coverage remained the same at 92.79% when pulling 26b1519 on nicoddemus:check-manifest into fc304b8 on pytest-dev:master.

looks good to me to remove the old scripts. We are missing an easy way to test a new pytest release against released versions of some plugins, don't we? devpi test X for packages coming from pypi doesn't work, only for packages uploaded to pypi indexes. that should change i guess because we could then run tests by a series of "devpi test X" while running from an index which contains the to-be-released version of pytest.

Coverage remained the same at 92.79% when pulling aaa547e on nicoddemus:check-manifest into fc304b8 on pytest-dev:master.

That should change i guess because we could then run tests by a series of "devpi test X" while running from an index which contains the to-be-released version of pytest.

That sounds neat. I've been using devpi-cloud-tester for some time to test releases, it would be simple to just add a bunch of selected pytest plugins to test them together with releases.

devpi has a --index option, but I guess that won't solve this because we need to tell devpi to test the package from PyPI, but get the dependencies from the index (when possible) and fall back to PyPI for the others as it usually does anyway.

there is one prooblem with this PR: the "check-manifest" call depends on version control and "devpi test" only installs the packages and does not have .hg/.git etc. directories. so linting fails with "devpi test". It seems check-manifest has no way to go without VCS. What do we do?

Oh you're right. Hmm how about moving the command to a separate env, manifest, which is not listed in tox's env-list but is called explicitly by one of the CI services (say Travis)? This way it won't get executed by devpi test, but will run continuously on CI.

On Fri, Nov 11, 2016 at 07:08 -0800, Bruno Oliveira wrote:

Oh you're right. Hmm how about moving the command to a separate env, manifest, which is not listed in tox's env-list but is called explicitly by one of the CI services (say Travis)? This way it won't get executed by devpi test, but will run continuously on CI.

probably works, feels a bit like a workaround. A more direct workaround might be to call a script a script which calls check-manifest only if there is a .git dir and otherwise prints a "no .git directory found, skipping checking the manifest file" or so.

I like your plan better. 😁

I will open a PR later.