include setup_requires as unzipped universal wheels in the sdist in .eggs

[ghost]

Originally reported by: RonnyPfannschmidt (Bitbucket: RonnyPfannschmidt, GitHub: RonnyPfannschmidt)

---

this relates to #375 and #376

once unzipped wheels are used like unzipped eggs, it seems like a potential extra help
to just include the exact setup_requires in a sdist, so no network access is needed to use the setup.py

to even extend on this, ez_setup could also be extended to put a unzipped wheel of setuptools right at the start of sys.path enabling the use of very recent setuptools in sdists without depending on the environment

---

• Bitbucket: https://bitbucket.org/pypa/setuptools/issue/377

[astrojuanlu]

I just moved a dependency from install_requires to setup_requires and instead of using the coresponding wheel, it tried to build it, failing with the classical Unable to find vcvarsall.bat error. Is this behavior a consequence of this issue (or #375, or #376) or may I file a separate one?

[jaraco]

include the exact setup_requires in a sdist, so no network access is needed to use the setup.py

It's still vendoring, even if it's only for setup_requires, which brings along all of the dangers of vendoring (a buggy version is permanently embedded, newer versions don't become available, platform-specific needs are not honored). Not all packages are universal wheels, so what happens in the case the dependency can't support a universal wheel? Does it get omitted and it needs to be built from the index? How does an installer know which dependencies are missing? Just those that are not already satisfied by the vendored versions?

I just moved a dependency from install_requires to setup_requires and instead of using the coresponding wheel, it tried to build it, failing with the classical Unable to find vcvarsall.bat error. Is this behavior a consequence of this issue (or #375, or #376) or may I file a separate one?

Yes, Juanlu, I think you need to file a separate ticket. The "unable to find vcvarsall.bat" error is probably unrelated, and only related to the fact that you need a dependency that your environment isn't suited to build.

[astrojuanlu]

Yes, Juanlu, I think you need to file a separate ticket. The "unable to find vcvarsall.bat" error is probably unrelated, and only related to the fact that you need a dependency that your environment isn't suited to build.

Precisely, my question is if "python setup.py install won't use wheels for dependencies that are in setup_requires" is already a known issue that it's been reported somewhere or if it's a particular problem of mine that I should describe in more detail.

[jaraco]

if "python setup.py install won't use wheels for dependencies that are in setup_requires" is already a known issue

I see. You want setuptools to install wheels so that your setup-time dependencies don't need to be built.

python setup.py install will use wheels in the sense that if there are packages installed by pip as wheels, it will use them. If the packages required to run setup (setup_requires) aren't present, setuptools will attempt to install them using easy_install, and easy_install doesn't support installing wheels (#78) or using wheels in a temporary context (as setup_requires does).

I think if #78 and #376 were implemented, that would address your needs, so there probably isn't a need for a separate ticket in that case.

[astrojuanlu]

python setup.py install will use wheels in the sense that if there are packages installed by pip as wheels, it will use them. If the packages required to run setup (setup_requires) aren't present, setuptools will attempt to install them using easy_install, and easy_install doesn't support installing wheels (#78) or using wheels in a temporary context (as setup_requires does).

Thank you very much @jaraco, that explanation clarifies my issue :)

[enkidulan]

Is there any progress on this?

[jaraco]

No progress, and as far as I know, no one is working on it. Contributions are welcome, but this is a challenging proposition.

[jaraco]

As setup_requires is being eliminated (#2823), this issue is obsolete. Enhancements to build environment optimization should be made in the packaging standards.