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

Python 3.9.0rc recipe #389

Merged
merged 56 commits into from
Oct 6, 2020
Merged

Conversation

ocefpaf
Copy link
Member

@ocefpaf ocefpaf commented Sep 16, 2020

xref #270. @willingc You opened it but we never addressed this properly. The main issue is bandwidth to catch up with upstream, even if that will happen only on the RCs. I'm investigating the patches here and I hope to be able to work with upstream to see if we can get some of them merged (or dropped for something better).

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

recipe/meta.yaml Outdated
- patches/0012-Fix-find_library-so-that-it-looks-in-sys.prefix-lib-.patch
- patches/0013-Disable-new-dtags-in-unixccompiler.py.patch
- patches/0014-Fix-cross-compilation-on-Debian-based-distros.patch
# - patches/0015-Disable-registry-lookup-unless-CONDA_PY_ALLOW_REG_PA.patch
Copy link
Member Author

Choose a reason for hiding this comment

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

@mingwandroid this is inside a if (!Py_IgnoreEnvironmentFlag) now. Does that solve our problem or do we still need to refresh this patch.

Copy link
Contributor

@mingwandroid mingwandroid Sep 19, 2020

Choose a reason for hiding this comment

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

I highly recommend keeping this. Without it, installers will fail, for example. We don't set Py_IgnoreEnvironmentFlag and until we do (if we want to) and get this enforced in all the places we need to this is crucial.

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually I am not sure. I mean, this is our own var that some may have used.. if no one is using it then yeah, let's drop it.

@willingc
Copy link

@ocefpaf No worries; we're all busy. Thanks for looking into it. If not this release, there will always be a new one 😉

@ocefpaf ocefpaf force-pushed the 3.9rc1 branch 2 times, most recently from 2888305 to 6220041 Compare September 17, 2020 15:53
@ocefpaf ocefpaf changed the title Python 3.9.0rc1 recipe Python 3.9.0rc recipe Sep 18, 2020
@ocefpaf
Copy link
Member Author

ocefpaf commented Sep 19, 2020

@mingwandroid all the patches are refreshed. It looks like we can drop 0021-roll-back-2e33ecd-for-py_compile.main.patch and I'm not 100% sure I got =0015-Disable-registry-lookup-unless-CONDA_PY_ALLOW_REG_PA.patch correctly, but the rest seems fine.

Do you have an idea of which ones we should prioritize and try to push upstream?

I'll investigate the Windows failure later, not sure what is going on. Linux and macOS are building correctly, the problem seems to be the lack of python_abi metapackage for Python 3.9. (Thanks @isuruf for pointing that out to me.)

@mingwandroid
Copy link
Contributor

Hey @ocefpaf,

My thoughts on upstreaming/dropping, patch-by-patch..

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0000-Fix-off-by-one-error-in-_winapi_WaitForMultipleObjec.patch
.. is in review upstream already. There was some pings about my PR yesterday. We can drop this once merged. Without it, you cannot install Miniconda or Anaconda (or do various other things) on a 64+ thread Windows machine. John Carmack raised this bug with us on twitter!

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0001-Add-Anaconda-Distribution-version-logic.patch
Not appropriate for upstream unless someone fancies tackling a general way to hook this bannering stuff. Anyway, conda-forge do not apply this one AFAIR.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0002-Darwin-Add-arch-x86_64-to-UnicCCompiler-ld_args.patch
Probably needs fixing for osx-aarch64 (ping @isuruf) maybe it can be removed? Worth checking.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0003-Win32-Change-FD_SETSIZE-from-512-to-2048.patch
Should be pushed upstream so that upstream Python is similarly capable.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0004-Win32-distutils-Add-support-to-cygwinccompiler-for-V.patch
Good simple bug fix, may want to add vs2019 stuff to it and push it upstream.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0005-Do-not-pass-g-to-GCC-when-not-Py_DEBUG.patch
Not sure about this one. We may want to check the size of extension modules if we removed it and if there is a difference then think about an upstreaming strategy for it.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0006-Support-cross-compiling-byte-code.patch
This has been important when needing to bootstrap our Python on a different linux arch. I don't know if things are better upstream in this regard but since this patch rebases cleanly my firm suspicion is no, it hasn't. I expect the chances of upstream wanting to touch this sort of code to be low.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0007-Win32-Fixes-for-Windows-GCC-interop-needed-by-RPy2-a.patch
Good, simple fix, should be upstreamed IMHO.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0008-Darwin-Look-in-sysroot-usr-lib-include-if-sysroot-is.patch
We could try to build without this, if it works (for building a load of extensions without problem) then consider dropping it, otherwise we should think about upstreaming it.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0009-runtime_library_dir_option-Use-1st-word-of-CC-as-com.patch
This patch allows setting e.g. "CC=gcc -g0", or "CC=ccache gcc", we should perhaps try to upstream it and get some opinions on it. I wonder if for correctness, we should be splitting by IFS though instead of ' '.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0010-Win32-Do-not-download-externals.patch
Not appropriate for upstreaming, this is to speed up our builds by not downloading things we don't need.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0011-Add-support-for-_CONDA_PYTHON_SYSCONFIGDATA_NAME-if-.patch
Not appropriate for upstreaming unless someone wants to have a go at supporting this sort of thing upstream in a way that they're likely to approve of. I doubt they would want this though. It's just a necessary evil for us, IMHO.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0012-Fix-find_library-so-that-it-looks-in-sys.prefix-lib-.patch
This patch makes Python better respect HFS (executable_path/../lib) when looking for dylibs on macOS. We could propose it upstream but it is quite conda-ecosystem specific IMHO.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0013-Disable-new-dtags-in-unixccompiler.py.patch
Here, conda-build is opinionated (as am I) about the new-dtags feature of glibc/the GNU linker. This prevents DSO interposition on Linux which many consider a security risk. The comment gives more detail. I don't know how upstream would feel about it, probably some would like it and some would dislike it!

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0014-Fix-cross-compilation-on-Debian-based-distros.patch
This should be pushed upstream. Debian-ism paths shouldn't be looked in when cross compiling.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0015-Disable-registry-lookup-unless-CONDA_PY_ALLOW_REG_PA.patch
This is important and not upstreamable IMHO.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0016-Unvendor-openssl.patch
https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0017-Unvendor-sqlite3.patch
Conda-ism, this implements our preference to use our own shared libraries. Not appropriate for upstream.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0018-venv-Revert-a-change-from-https-jackfan.us.kg-python-cp.patch
Conda-isms. If we don't want to do this then we'd need to align our layout on Windows better with upstream. I expect that would break a lot of things.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0019-Win-Add-back-the-DLLSuffix-used-to-find-the-openssl-.patch
@mariusvniekerk? Looks like something upstream might consider. But we'd likely need to also change the OpenSLL vcxproject files (that we do not use but upstream does, I think!)

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0020-Use-ranlib-from-env-if-env-variable-is-set.patch
We should try to get this upstreamed. I don't think it's very controversial (though changing the build system of Python in any way is somewhat!)

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0021-roll-back-2e33ecd-for-py_compile.main.patch
@duncanmmacleod? Seems like a bug upstream to me and we could try to upstream this fix.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0022-Add-CondaEcosystemModifyDllSearchPath.patch
I would rather not have had to write any of this but changes to upstream made it necessary. If you don't use this you will have problems, or if you don't your friends on Windows will. For my perspective 0% chance of being upstreamed.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0023-Add-d1trimfile-SRC_DIR-to-make-pdbs-more-relocatable.patch
Upstream would likely consider this.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0024-Doing-d1trimfile.patch
.. and maybe (along with) this.

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0025-egg-debugging-with-Windows-debug-builds.patch
There's a bug in egg stuff on Windows, but no one ever uses it. This was something I added when investigating that but I've completely lost the thread of that work now! Drop?

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0026-Revert-part-of-https-bugs.python.org-issue33895-http.patch
@isuruf and I are in alignment that we'll neuter this patch but make it something you can use via an env var to aid debugging.

So we need a plan of attack. I'm more than happy to ask for time to be set aside for me to handle pushing these, starting with the easy ones first and seeing how far I go, but anyone is (always) welcome to propose any of my patches and ping me in the comments if they wish.

@mingwandroid
Copy link
Contributor

I used AnacondaRecipes URLs in my last comment, sorry about that, but it's to make it easier for me when/if I tackle this.

@duncanmmacleod
Copy link
Contributor

https://github.com/AnacondaRecipes/python-feedstock/blob/master/recipe/patches/0021-roll-back-2e33ecd-for-py_compile.main.patch
@duncanmmacleod? Seems like a bug upstream to me and we could try to upstream this fix.

@mingwandroid, this is already fixed upstream, see bug report and fix python/cpython#17134. Actually, that specific patch isn't in 3.9.0rc1, but I've checked the contents of that tarball and the bug that my patch fixed isn't there, so this one can be dropped either way.

@ocefpaf
Copy link
Member Author

ocefpaf commented Sep 21, 2020

@mingwandroid thnaks for the compilation of the patch status. @duncanmmacleod indeed the 0021-roll-back-2e33ecd-for-py_compile.main.patch seems to be in, I commented it out and I'm planning of removing it next iteration.

I'm copying #389 (comment) in a doc so we can tackle one at a time. We already have @willingc 👀 here ;-p

@mingwandroid
Copy link
Contributor

@zooba may want to take a look too?

@isuruf
Copy link
Member

isuruf commented Sep 24, 2020

The test error is because of a cython dependency in tests. not sure why it was added. Removing cython should unblock the tests.

recipe/meta.yaml Outdated
- ripgrep
- cmake
- ninja
- setuptools
Copy link
Member

Choose a reason for hiding this comment

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

@ocefpaf, need to remove this too

recipe/meta.yaml Outdated
Comment on lines 218 to 222
- pushd distutils.cext
- python setup.py install -v -v
- python -c "import greet; greet.greet('Python user')" | rg "Hello Python"
- popd
Copy link
Member

Choose a reason for hiding this comment

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

These 4 lines too

@mingwandroid
Copy link
Contributor

Rather than removing all these tests, can you elide them when the patch number is 0? I think that way, we can do a build 1 once the necessary deps are present and get the benefits of the tests back.

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

  • The recipe must have a build/number section.
  • The outputs section contained an unexpected subsection name. string is not a valid subsection name.

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

  • The recipe must have a build/number section.

@mingwandroid
Copy link
Contributor

This builds now. What's the plan with tzdata though?

@mingwandroid
Copy link
Contributor

Does anyone know why the linter is complaining? Each output has build/number: 0 now.

@conda-forge-linter
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@isuruf isuruf changed the base branch from prerelease to master October 6, 2020 15:43
@mingwandroid
Copy link
Contributor

This doesn't address the tzdata thing. We can do that in a follow up PR?

@ocefpaf
Copy link
Member Author

ocefpaf commented Oct 6, 2020

@mingwandroid are you OK pointing this to the rc label, switching to the rc2, and merging it there first? That way we can wait for the tzdata stuff and prepare this for master in another PR.

@isuruf isuruf changed the base branch from master to prerelease October 6, 2020 16:39
@ocefpaf
Copy link
Member Author

ocefpaf commented Oct 6, 2020

This builds now. What's the plan with tzdata though?

#392

@mingwandroid awesome work! We will merge this in the rc label for now, without the tzdata, and I'll port this recipe to master as soon as we have conda-forge/tzdata-feedstock#1

@ocefpaf ocefpaf added the automerge Merge the PR when CI passes label Oct 6, 2020
@github-actions github-actions bot merged commit bdf1d97 into conda-forge:prerelease Oct 6, 2020
@github-actions
Copy link
Contributor

github-actions bot commented Oct 6, 2020

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

  • linter: passed
  • azure: passed

Thus the PR was passing and merged! Have a great day!

@ocefpaf ocefpaf deleted the 3.9rc1 branch October 6, 2020 17:41
@mingwandroid
Copy link
Contributor

Nice. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge Merge the PR when CI passes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants