Add unit tests for _download_url?

[pganssle]

Currently _download_git, _download_svn and _download_hg are all not getting hit by the test suite.

It will probably be useful to add unit tests that hit (via the public interface) those code paths.

I think the easiest way to get a useful version of this working is to mock out os.system and check that the correct system calls are made.

We can and possibly should also make integration tests that actually make the relevant system calls, but we can defer those later because they have some more dev-ops-y implications.

[benoit-pierre]

Or just deprecate them?

[pganssle]

@benoit-pierre Any change to this code is going to give us negative diff coverage because it's changing untested code, which makes it hard to evaluate whether such changes (including changes that raise DeprecationWarnings) are safe to merge.

If the eventual goal is to deprecate/remove this functionality, then we can skip the integration tests.

[jaraco]

So these calls are soft-deprecated in the sense that easy_install is deprecated. The issue remains that setup_requires still relies on easy_install and eggs. I'm okay leaving these untested as I consider these use cases largely unsupported and the workaround is to use pip and pyproject.toml to prevent setup_requires from being activated.

[pganssle]

@jaraco I think we should do the basic smoke tests (i.e. mock out the system calls), if only so that the CI won't complain about coverage issues when we make changes like #1499.

Also, when we do "hard" deprecate them, we'll want tests to make sure the deprecation warnings are raised, and having some existing "mock tests" will make that easier (since we can just inject the "pytest.warns" assertion directly into those tests).

[vitoace]

I'd like to work on this

[serjx86]

Looking into it...

[kanikas3]

working on this with @vitoace and @serjx86