-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: share wheels across Tox environments #12
Comments
Keying on I think rather the solution lies in giving power to the user to deal with this by just having configuration - eg: this env uses this wheel. In your situation you could just use |
Perhaps I misunderstand how |
Try this: [testenv]
wheel = true
[testenv:docs]
wheel_build_env = py38 |
My actual configuration is more complicated than that, but this seemed to achieve my goal for [testenv]
wheel = true
wheel_pep517 = true
wheel_build_env =
docs: py37
!docs: {envname} Where it really doesn't work is with factors: Incidentally, this only works because Python 3.7 is the default Python on my system. I'm not sure how to use In the meantime,
This made me think you can only use |
Alright, does the referenced commit adequately address your usecase? |
The changed rendered incorrectly. Maybe you want something more like this, with the Note that you can also use ``wheel_build_env`` for situation where you have many environments for the same interpreter:
.. code-block:: ini
[testenv:py38]
; regular testing
[testenv:py38-extras]
; tests with optional dependencies
wheel_build_env = py38
[testenv:docs]
; docs building
wheel_build_env = py38 Anyway, that's a good addition for now because it would have gotten me started. I still think being able to form groups of environments or generative environment dependencies would be useful as described in the OP. I understand your hesitancy to detect things automatically, but that can be a separate question from groups/generative deps. In particular, your new docs, while a good start, don't address the missing features I mentioned here #12 (comment) |
I just don't want to reimplement parts of pip when the problem can simply be solved with some configuration. It's not like people need to shuffle around envs all day long to require such a complex feature. |
Superficially similar to #10, which is about downloading a pre-built wheel. What I'm looking to do is build only one wheel per
{envpython}
.† For example, suppose I run tests in thepy37
environment on Python 3.7 and in thepy38
environment on Python 3.8, and then build documentation in thedocs
environment. Ifdocs
uses, say, Python 3.7, thendocs
does not need to build a wheel, but could instead share with thepy37
environment. In other words, I'd like a way fortox -e py37,py38,docs
to run make-wheel twice instead of three times. (In my particular use case,skip_install=True
for thedocs
environment is off the table because I have to compile Cython modules for Sphinx autodoc to consume.)†I'll admit to some confusion about the relationship between
basepython
and{envpython}
. I think what matters for which wheel an environment needs is{envpython}
, but maybe I'm wrong.Suggested interface
Ideally, tox-wheel would automatically detect the
{envpython}
version. There would be a per-environment option to override that detection in case, for example, I want to use different build settings (e.g., CFLAGS) in different environments. This per-environment setting might be calledwheel_from
(orwheel_shared_with
or the like) and take the name of one or more other environments. The relationship would be implicitly bidirectional: Ifdocs
can usepy37
's wheel, thenpy37
can usedocs
's wheel. Ifwheel_from
is set to the empty list, then the auto-detection of{envpython}
would be turned off in favor of that environment always getting its own wheel (the current behavior), even if the environment is listed in other environment'swheel_from
setting.Implementation notes
I don't know how detecting
{envpython}
would work because I'm insufficiently familiar with Tox's internals. For determining which environments can share a wheels, crawl the settings for the environments that will run, and use a union-find data structure to keep track of which ones can get lumped together (you don't need the full fancy union-find algorithm because the number of environments tends to be quite small; my point here is merely that you're coming up with disjoint sets of environments to lump together, each of which gets its own wheel). Then look for any emptywheel_from
settings and pull them out of any of the groups to place them on their own. For each of those groups, build a wheel.The text was updated successfully, but these errors were encountered: