Keep python pinning in hashing if there's a space

[isuruf]

No description provided.

[mingwandroid]

@msarahan, could you give this a review? It's part of the multiple python interpreter support drive.

[msarahan]

It seems cleaner to me to just include all python pinning in the hashing, rather than restricting it only to cases with a space. We didn't do that because of the legacy standard of putting python in the build string directly. Python is also so much more commonly a point of interest that keeping it in the build string kept it easy for people to visually inspect packages. With .conda files, pulling out the hash contents should now be fast enough that it might be feasible to get rid of python and the other special-cased junk in the build string and have only the hash.

That's definitely not a conversation I'd wade into recklessly, though. People will feel strongly about it.

If you keep only this change, how does this handle the rest of the build string? What do you envision a final package filename looking like?

[isuruf]

For pypy packages it will have py36 in the build string, but there'll also be a hash.

I wanted this to be backward compatible so that people relying on --skip-existing will not get affected.

[msarahan]

seems reasonable to me. I'd say give it a try.

[isuruf]

I've marked this WIP, till I try it out. I'll let you know if this works.

[isuruf]

This works as expected. I've removed WIP

[mingwandroid]

Thank you!

[isuruf]

I don't suppose there's a new release that's going to happen soon, right? 😃

[mingwandroid]

Yes. ASAP. But probably not today. I must make patchelf the default patcher first.

[github-actions]

Hi there, thank you for your contribution!

This pull request has been automatically locked because it has not had recent activity after being closed.

Please open a new issue or pull request if needed.

Thanks!