5 ms·

I don’t think that I’d try to slip an additional build time compiler in in a minor version update. While it’s not a runtime change, it is going to affect a lar

I don’t think that I’d try to slip an additional build time compiler in in a minor version update. While it’s not a runtime change, it is going to affect a large number of people, and they will all post comments on any issue that matches their particular “can’t install because we can’t find the header foo.h”. (Speaking as someone who maintains a popular c/python package that is difficult to compile. )

chrismorgan 6y ago
If it were something that required building from source, I’d be more open to considering the build dependencies part of the API (though I’d still assess it on a case-by-case basis), but so long as you provide wheels, people don’t need to build the library, and so build dependencies definitely aren’t a part of the API. In the case of cryptography, I gather that the vast majority of complainants were on Gentoo (which builds things from source) or Alpine (for Docker containers, because many-musl wasn’t a thing, so no wheel could be provided) or an ancient architecture that should be allowed to rot anyway (for reasons that have been discussed in other recent articles). Yeah, it’s a fair number of people affected in the end, but probably a very small fraction of everyone; and once many-musl is defined in pip and cryptography uses it, it’ll be close enough to no one as no matter. Remember also that if you’re using SemVer, a major version bump forms a schism because you can’t expect everyone to upgrade immediately, so major version bumps should not be performed lightly, especially for any sort of security-critical thing if you’re not going to maintain the old. I agree with Alex that, if using SemVer, bumping major would have been wrong here.
- wiredfool 6y ago
  What I'm saying is that despite providing tens of wheels per release, pip still sometimes gets the source version, and it's predominately the unskilled users that descend en-masse to complain that it won't install, there's this error message, and what does it mean. As a maintainer, this sucks. Even if it's a very small fraction, the internet is large, and my time isn't. I disagree with Alex. I understand his point of view, but I disagree. I also disagree with his project's decision to print a non-disableable warning on import in python 2.7, and then justifying the noisy warning based on "we didn't want people to disable it". One legacy project I'm working on is trying to get off 2.7. It's a long process, we know about it, and warnings like this all over the logs simply don't help.
  - mrtranscendence 6y ago
    But incrementing the major version wouldn't have helped those who weren't pinning to an earlier version, something I suspect applies to many of those unskilled users.

chrismorgan 6y ago

If it were something that required building from source, I’d be more open to considering the build dependencies part of the API (though I’d still assess it on a case-by-case basis), but so long as you provide wheels, people don’t need to build the library, and so build dependencies definitely aren’t a part of the API. In the case of cryptography, I gather that the vast majority of complainants were on Gentoo (which builds things from source) or Alpine (for Docker containers, because many-musl wasn’t a thing, so no wheel could be provided) or an ancient architecture that should be allowed to rot anyway (for reasons that have been discussed in other recent articles). Yeah, it’s a fair number of people affected in the end, but probably a very small fraction of everyone; and once many-musl is defined in pip and cryptography uses it, it’ll be close enough to no one as no matter. Remember also that if you’re using SemVer, a major version bump forms a schism because you can’t expect everyone to upgrade immediately, so major version bumps should not be performed lightly, especially for any sort of security-critical thing if you’re not going to maintain the old. I agree with Alex that, if using SemVer, bumping major would have been wrong here.

wiredfool 6y ago
What I'm saying is that despite providing tens of wheels per release, pip still sometimes gets the source version, and it's predominately the unskilled users that descend en-masse to complain that it won't install, there's this error message, and what does it mean. As a maintainer, this sucks. Even if it's a very small fraction, the internet is large, and my time isn't. I disagree with Alex. I understand his point of view, but I disagree. I also disagree with his project's decision to print a non-disableable warning on import in python 2.7, and then justifying the noisy warning based on "we didn't want people to disable it". One legacy project I'm working on is trying to get off 2.7. It's a long process, we know about it, and warnings like this all over the logs simply don't help.
- mrtranscendence 6y ago
  But incrementing the major version wouldn't have helped those who weren't pinning to an earlier version, something I suspect applies to many of those unskilled users.