Cibuildwheel: install order in test enviroment

[Czaki]

I see that in code first package is installed then test requirements. It is intentional?

In some cases it can make build fail because some changes in new version of package (in my case it is that package use manylinux2014 platform tag for wheel and I would like to build on manylinux2010). If replace order then user can force to use older version of package.

from linux.py:

pip install "${{repaired_wheels[0]}}"{test_extras}

# Install any requirements to run the tests
if [ ! -z "{test_requires}" ]; then
    pip install {test_requires}
fi

[YannickJadoul]

I think this is intentional, because packages should be able to be installed without the test requirements, right? CIBW_TEST_REQUIRES logically only comes afterwards, to install extra packages (e.g. pytest or so) to run the tests.

So I think your problem is something else. If you make a manylinux2010 wheel, but your dependencies only support manylinux2014, this feels like a problem. Because users will have the same problem when installing your manylinux2010 wheel. Maybe this is something to be fixed in setup.py?

[Czaki]

There is case when one of dependent package with version 1.5.x is build against manylinux1 tag and from version 1.6.x is build against manulinux2014 tag. And my package works fine with both versions. And it is possible to build it against manylinux2010. So I would like to test it against 1.5.x line, but not force it in setup.py file.

Currently, in my case i use PR #242 for this (check fail because of chocolatey fail, can you restart it?).

Other problem is that manylinux2014 needs pip>=19.3 and in many places system pip is 18.1. And packages like PyQt are available in repository.

[YannickJadoul]

If that's the case, why don't you just install it in CIBW_BEFORE_BUILD? You have all the freedom to do whatever you want, there.

[Czaki]

Because test are ins separated virtualenv? And this environment is created when there is test_command?

[YannickJadoul]

Because test are ins separated virtualenv? And this environment is created when there is test_command?

Ugh, yes. Sorry, I forgot about that :-|

Yes, OK, now I also understand the problem of #242 better. Then we should indeed probably make some kind of a preparation step for the tests.

But I still think this order of installing the package before the test requirements is better, because the package installation gets tested separately from the tests, then.

[Czaki]

If #242 is merged (or something similar) then problem will be fixed. User will have solution for such case.

On begin I create #242 from different reason. I need to use more modern version of library that is available in centos 6. So I need to compile it manually. And need to unset some environment variables that point to install location.

[joerick]

I agree with @YannickJadoul, in principle, the order of operations here seems correct in my mind. If #242 will solve this specific problem for you, I'd rather do that.

[YannickJadoul]

@Czaki Just noticed: there might be another solution, to the one we now have. #242 is merged and it's maybe more intuitive/useful for other things so I'm definitely not saying to remove it or anything, but it might be nice to just add another solution here, in case it's ever useful:

Setting PIP_ONLY_BINARY=... should force pip to look for a binary image that's compatible, rather than download the latest version as source dist and build it. (And maybe there are still other PIP_ options that would fix the version; i.e. through PIP_CONSTRAINT or so.)

[Czaki]

Setting PIP_ONLY_BINARY=... should force pip to look for a binary image that's compatible, rather than download the latest version as source dist and build it. (And maybe there are still other PIP_ options that would fix the version; i.e. through PIP_CONSTRAINT or so.)

Some packages has no wheel version. Only sources.

[YannickJadoul]

Some packages has no wheel version. Only sources.

I know. But weren't you saying that's the problem?

There is case when one of dependent package with version 1.5.x is build against manylinux1 tag and from version 1.6.x is build against manulinux2014 tag.

Or is that not about wheels but about not being able to build it against pre-manylinux2014?

[Czaki]

Ok. This case can be covered. But what if I do not want apply this to all dependecis?

[YannickJadoul]

You have control over that as well:

  --only-binary <format_control>
                              Do not use source packages. Can be supplied multiple times, and each time adds to the existing value. Accepts either :all: to disable all source packages, :none: to empty the set, or one or more package names with commas between them. Packages
                              without binary distributions will fail to install when this option is used on them.

Again, not saying this is a better solution than #242 in general, but it might sometimes be useful :-)

[Czaki]

Good to know.