Fixing macOS CI and tests after lastest release of virtualenv

[YannickJadoul]

Isolating build issues from #185, seemingly related to virtualenv 20.

(Sorry for the PR pollution, but this might be the easiest way to test out a few things.)

[YannickJadoul]

@Czaki See here as well.

[Czaki]

This is next things that show why PR #256 is really important...

[YannickJadoul]

This is next things that show why PR #256 is really important...

Ah, yes, I still need to give that a look!
Yes, maybe. But I would still like to be able to use the latest version of packages, perhaps. Or at least not wait for cibuildwheel updates to use newer versions.

[Czaki]

Ah, yes, I still need to give that a look!
Yes, maybe. But I would still like to be able to use the latest version of packages, perhaps. Or at least not wait for cibuildwheel updates to use newer versions.

Problem is when next release of package breaks the cibuildwheel like virtualenv. You have no information about this until someone try to introduce next change.

If dependabot will be introduced it will create PR with upgraded version of package and then build will failed and you will have information that it is a problem.

[YannickJadoul]

I think you're right, @Czaki, that the installed scripts keep a reference to the old virtualenv from the first part of the test.

Now the question is why, and if we can reproduce it with a simple script?

[YannickJadoul]

Ah, yes, I still need to give that a look!
Yes, maybe. But I would still like to be able to use the latest version of packages, perhaps. Or at least not wait for cibuildwheel updates to use newer versions.

Problem is when next release of package breaks the cibuildwheel like virtualenv. You have no information about this until someone try to introduce next change.

If dependabot will be introduced it will create PR with upgraded version of package and then build will failed and you will have information that it is a problem.

I understand. I am just afraid we will need to make a lot of releases of cibuildwheel, this way. Anyway, that's another discussion, I guess.

[Czaki]

For me it is connected with bug mentioned in virtualenv documentation.

sciript draft :

ls default_python_path/site-packages
python -m virtualenv
activate venv
pip install something 
ls default_python_path/site-packages

I understand. I am just afraid we will need to make a lot of releases of cibuildwheel, this way. Anyway, that's another discussion, I guess.

Why? #256 offers to run in most modern mode, allow to define own package version and you will have no problem that your build system stops working because someone upgrade his own package.

I do no see any profit of create release for every version bump.

[YannickJadoul]

Why? #256 offers to run in most modern mode, allow to define own package version and you will have no problem that your build system stops working because someone upgrade his own package.

I proposed that in the issue, yes. But I still need to have a good look at #256 :-(

[Czaki]

@joerick How it looks from your side?

[YannickJadoul]

@Czaki Thanks for the demo-script. I've added a comment to the existing issue: pypa/virtualenv#1561 (comment)

[YannickJadoul]

If this works, I'll merge it. It's getting too annoying that the master is broken.

[joerick]

I guess this needs a release ASAP?

[Czaki]

This error occuress only when someone call cibuildwheel twice on same macos machine. So it is no such critical. Maybe may wait on #185.

[joerick]

ah, okay. That explains why we haven't seen any bug reports from users for this :)