Skip to content
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

bpo-40747: Make py_version_nodot 3_10 not 310 #20333

Closed
wants to merge 14 commits into from

Conversation

mattip
Copy link
Contributor

@mattip mattip commented May 23, 2020

Fixes pypa/packaging#308, pypa/wheel#354, and maybe pypa/pip#8312.

The current value of 310 is ambiguous so use 3_10 instead. While this may fix pip and wheel.bdist_wheel, it has the potential to break other projects that depend on _PY_VERSION_SHORT_NO_DOT being 2 characters or that calculate the value via '%d%d' % sys.version_info[:2] themselves.

https://bugs.python.org/issue40747

@pablogsal
Copy link
Member

pablogsal commented May 23, 2020

Hmmm, this change may have some other unforeseen consequences. For instance, IIRC this affects the path (indeed, there is a test failing for Windows). Someone more familiar with packaging should take a look as well to make sure this does not have some other unwanted consequences. CC: @brettcannon

@ned-deily
Copy link
Member

ned-deily commented May 24, 2020

Should probably have @zooba take a look as well. I don't see where the short no dot variable from either copy of sysconfig is used in Unix-y builds of cpython. I've done a quick macOS framework style build (--enable-framework) and I haven't noticed any obvious change in paths or any test suite failures. I'd be inclined to not make the change though unless it is likely to cause problems for downstream packages that do use the variable.

But is it really ambiguous? cpython versions are always of the form 3.x, never 3.x.y, as far as constructing path names in builds, AFAIK. That is, for unix-y builds using autoconf. @zooba could speak for the Windows build system.

And I'm assuming by the time we get to Python 9 there will be bigger issues :)

@pablogsal pablogsal requested a review from zooba May 24, 2020 01:52
@brettcannon
Copy link
Member

It's ambiguous from the perspective of what is "310": 3.10 or 31.0? While we don't exactly plan on changing our numbering scheme right now, this is an ambiguity. Plus it just looks odd to me, which does somewhat matter as this will show up in wheel file names.

@mattip
Copy link
Contributor Author

mattip commented May 25, 2020

The FAQ for PEP 425 has this:

Why isn't there a . in the Python version number?
CPython has lasted 20+ years without a 3-digit major release. This should continue for some time. Other implementations may use _ as a delimeter, since both - and . delimit the surrounding filename.

I think "major release" in this context means 3.4, 3.5, 3.6, ... so we are about to hit a 3-digit major release.

@mattip
Copy link
Contributor Author

mattip commented May 26, 2020

Tests pass, including one new test for consistency.

configure.ac Outdated
AC_MSG_RESULT($SOABI)

# Release and debug (Py_DEBUG) ABI are compatible, but not Py_TRACE_REFS ABI
if test "$Py_DEBUG" = 'true' -a "$with_trace_refs" != "yes"; then
# Similar to SOABI but remove "d" flag from ABIFLAGS
AC_SUBST(ALT_SOABI)
ALT_SOABI='cpython-'`echo $VERSION | tr -d .``echo $ABIFLAGS | tr -d d`${PLATFORM_TRIPLET:+-$PLATFORM_TRIPLET}
ALT_SOABI='cpython-'`echo $VERSION | tr -d "." "_"``echo $ABIFLAGS | tr -d d`${PLATFORM_TRIPLET:+-$PLATFORM_TRIPLET}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On macOS, at least,

$  ./configure --with-pydebug
[...]
checking SOABI... cpython-3_10d-darwin
usage: tr [-Ccsu] string1 string2
       tr [-Ccu] -d string1
       tr [-Ccu] -s string1
       tr [-Ccu] -ds string1 string2
checking LDVERSION... $(VERSION)$(ABIFLAGS)
[...]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh. Strange it passes CI. Is the change on line 4740 also problematic? I cannot reproduce, could you try removing the " so that the "." "_" becomes . _

Copy link
Member

@ned-deily ned-deily May 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tr error doesn't cause the configure run to fail. It happens on the Linux CI runs, too: from the Github Ubuntu test:

676 checking SOABI... cpython-3_10d-x86_64-linux-gnu
677 tr: extra operand '_'
678 Only one string may be given when deleting without squeezing repeats.
679 Try 'tr --help' for more information.
680 checking LDVERSION... $(VERSION)$(ABIFLAGS)

(You don't see it in the log for the most recent Travis CI run because it appears that the build environment for the PR is cached and it didn't rerun configure.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed by removing the -d from the tr command. Checked it by rerunning autoconf to recreate configure from configure.am.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(FWIW the error makes sense: tr is either original replacement or -d original to delete)

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@mattip
Copy link
Contributor Author

mattip commented May 28, 2020

I have made the requested changes; please review again

@bedevere-bot
Copy link

Thanks for making the requested changes!

@ned-deily: please review the changes made to this pull request.

@mattip
Copy link
Contributor Author

mattip commented Oct 13, 2020

Alternatively, we don't really need to do this, since we're not even planning to get to Python 4.x, let alone 31.x ;) Seems like plenty of time to come up with alternative file layouts.

I am fine with closing this, but then pypa/packaging should align itself with that approach.

@mattip
Copy link
Contributor Author

mattip commented Oct 13, 2020

I searched Doc, Tools/msi, and PC/layout for nodot and (case insensitive) major and added fixes. The only change in Doc was the outdated directions for linking in windows, which did not mention the linking pragma in pyconfig.h.

@mattip
Copy link
Contributor Author

mattip commented Oct 13, 2020

somewhat surprisingly, CI passed with the MSI changes

jonringer added a commit to jonringer/nixpkgs that referenced this pull request Oct 13, 2020
A python 3.10 wheel would produce a wheel with the
platform tag as `cp310`, which would be invalid, as
only 3_10 is accepted by the wheel package.

See: pypa/packaging#308
     pypa/wheel#354
     python/cpython#20333
@pablogsal
Copy link
Member

Unfortunately, this issue is also blocking running the pyperformance suite with master. @zooba, as you requested changes, how would you like to proceed?

@brettcannon
Copy link
Member

We should aim to resolve this by the end of the core dev sprint so we can unblock the rest of the ecosystem.

@hugovk
Copy link
Member

hugovk commented Oct 13, 2020

We should aim to resolve this by the end of the core dev sprint so we can unblock the rest of the ecosystem.

For those of us who didn't know, it's next week:

The sprint is scheduled for Oct 19 - 23, 2020. This will be an online event instead of the in-person sprint.

Sounds good! Should it be added to https://python-core-sprint-2020.readthedocs.io/projects.html?

@brettcannon
Copy link
Member

@hugovk nah, it will just be something that some of us go and discuss on the side.

@brettcannon
Copy link
Member

brettcannon commented Oct 14, 2020

@hugovk I decided not to risk forgetting, so I went ahead and added it to the TODO list. Thanks for the idea! (Currently the build has not happened yet, so don't be shocked if you don't see it at the bottom.)

@brandtbucher
Copy link
Member

@pablogsal downgrading to pyperformance==1.0.0 is a temporary workaround.

@pablogsal
Copy link
Member

pablogsal commented Oct 14, 2020

@pablogsal downgrading to pyperformance==1.0.0 is a temporary workaround.

Thanks @brandtbucher ! Unfortunately, we were working on the benchmarks for the speed.python.org server and downgrading uses a different versions of the packages being tested and therefore the generated data cannot be compared with the previous data 🙁

@brettcannon
Copy link
Member

For fellow core devs: feel free to add/remove yourself from https://python-core-sprint-2020.readthedocs.io/projects.html#wheel-interpreter-naming-for-3-10 and I will try to schedule a meeting when we can chat about this. I will wait until Monday to schedule based on who does (not) want to attend to make it timezone friendly (e.g. Pablo I know is London and I'm Vancouver).

@pablogsal
Copy link
Member

I will wait until Monday to schedule based on who does (not) want to attend to make it timezone friendly (e.g. Pablo I know is London and I'm Vancouver).

My sleep schedule is already destroyed and I am a night person, so feel free to push the meeting closer to your timezone if needed 😉

@@ -10,7 +10,7 @@
</PropertyGroup>
<Import Project="..\msi.props" />
<PropertyGroup>
<DocFilename>python$(MajorVersionNumber)$(MinorVersionNumber)$(MicroVersionNumber)$(ReleaseLevelName).chm</DocFilename>
<DocFilename>python$(MajorVersionNumber)_$(MinorVersionNumber)$(MicroVersionNumber)$(ReleaseLevelName).chm</DocFilename>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably separate the minor and micro version of the doc filename too - python3_10_0.chm rather than python3_100.chm. The actual change ought to be somewhere under Doc, IIRC.

@ned-deily
Copy link
Member

FYI, I've built and run with the PR merged up to the current HEAD of master with both a vanilla installed Linux config and my standard macOS installer build. In both cases, no test failures due to the PR were noted. In both cases, I also ran python3.10 -m test.pythoninfo and searched the output for the substring 310. I found two instances of that:

  1. the zipfile path (which @zooba noted above). On Linux with an install prefix of /tmp/b:
    sys.path: ['/tmp/a', '/tmp/b/lib/python310.zip', '/tmp/b/lib/python3.10', '/tmp/b/lib/python3.10/lib-dynload', '/home/nad/.local/lib/python3.10/site-packages', '/tmp/b/lib/python3.10/site-packages']

  2. the cache_tag attribute of sys.implementation:
    sys.implementation: namespace(name='cpython', cache_tag='cpython-310', version=sys.version_info(major=3, minor=10, micro=0, releaselevel='alpha', serial=1), hexversion=50987169, _multiarch='i386-linux-gnu')

I have no opinion ATM of the importance of either one, just reporting them.

@brettcannon
Copy link
Member

@mattip we discussed this at the sprint and decided that once Steve's concerns are addressed and I write a quick PEP this week on the chnage we can merge the PR.

@zooba
Copy link
Member

zooba commented Oct 20, 2020

The docs filename change seems to be at line 108 of https://github.com/mattip/cpython/blob/py_version_nodot/Doc/conf.py

Turns out the MSI build in PR is using the "friendly" option that doesn't fail when the doc file is missing, but this line shows that it wasn't found.

I think we should be fine to just allow the extra dots in the .chm name though, rather than going to underscores. And actually, I think we should try going to dots in the DLL name as well. Windows should be able to handle it, and it's more consistent between libpython3.10.so and python3.10.dll than having the underscore in there.

And if we're going to cause (a few) people to have to update their code anyway, we may as well end up somewhere more consistent :)

@mattip
Copy link
Contributor Author

mattip commented Oct 20, 2020

I'm not sure I understand what still needs to be changed. Could a reviewer who does understand push changes to this PR?

@zooba
Copy link
Member

zooba commented Oct 20, 2020

I can push changes, just didn't want to intrude since you've been active.

@mattip
Copy link
Contributor Author

mattip commented Oct 20, 2020

@zooba or anyone else, please feel free to make any necessary changes to move this forward

@zooba
Copy link
Member

zooba commented Oct 21, 2020

I've had to reopen as #22858 with a branch on my own fork, since I can only edit mattip's through the web UI (which, as you'll see, was not going to be worthwhile).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Python 3.10: _version_nodot, interpreter_version disagree on how to format it