-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
CPython: Conan 2.0 #21387
CPython: Conan 2.0 #21387
Conversation
# Conflicts: # recipes/cpython/all/conanfile.py
I detected other pull requests that are modifying cpython/all recipe:
This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Should be good to go now, I think I got all of the pre-3.8 logic. |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reviewed the PR now, it's looking good, only minor details to be checked.
@property | ||
def _version_tuple(self): | ||
return tuple(self._version_number_only.split(".")) | ||
short_paths = True |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why short_paths is needed now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Python packages compiled versions of all of the modules shipped in the stdlib in a __pycache__
folder. These paths end up being very long, you can look at some of the hooks in the earlier runs of the PR to see such file names (./lib/python3.10/site-packages/setuptools/_distutils/__pycache__/versionpredicate.cpython-310.pyc
, for example).
It would be a bad idea to remove these, as I believe they would just get regenerated when they are used, breaking cache immutability.
recipes/cpython/all/conanfile.py
Outdated
)) | ||
if self.settings.compiler == "intel-cc": | ||
tc.configure_args.append("--with-icc") | ||
if os.environ.get("CC") or self.settings.compiler != "gcc": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if os.environ.get("CC") or self.settings.compiler != "gcc": | |
if self.settings.compiler != "gcc": |
Avoid using external environment variables, it will result in not reproducible scenarios.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was here prior, I'll double check that it doesn't break anything if removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I can actually remove this condition entirely, seems that the flag was removed in 3.8: https://github.com/python/cpython/blob/main/Misc%2FNEWS.d%2F3.8.0a1.rst#L7485
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Much better, please, remove then. Thank you for checking it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. The condition above it was also able to be removed.
recipes/cpython/all/conanfile.py
Outdated
# For debugging configure errors | ||
try: | ||
autotools.configure() | ||
except ConanException: | ||
with open(os.path.join(self.build_folder, "config.log"), 'r') as f: | ||
self.output.info(f.read()) | ||
raise |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# For debugging configure errors | |
try: | |
autotools.configure() | |
except ConanException: | |
with open(os.path.join(self.build_folder, "config.log"), 'r') as f: | |
self.output.info(f.read()) | |
raise | |
autotools.configure() |
Let's keep it simple, please. Who is working on the recipe is able to access the build folder and read any file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, this was mainly to debug the xvmc issue in CCI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
recipes/cpython/all/conanfile.py
Outdated
if (os.path.isfile(os.path.join(self.package_folder, "lib"))): | ||
# FIXME not sure where this file comes from | ||
self.output.info(f"{os.path.join(self.package_folder, 'lib')} exists, but it shouldn't.") | ||
rm(self, "lib", self.package_folder) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (os.path.isfile(os.path.join(self.package_folder, "lib"))): | |
# FIXME not sure where this file comes from | |
self.output.info(f"{os.path.join(self.package_folder, 'lib')} exists, but it shouldn't.") | |
rm(self, "lib", self.package_folder) | |
# FIXME not sure where this file comes from | |
rm(self, "lib", self.package_folder) |
Let's simplify: The rm
only removes files, and does not raise error for file not found.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might remove this hack altogether, I don't know if it ever actually worked. I'll check through some logs to see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems intermittent, and actually hasn't happened recently (only checked some recent logs, not going through all of them). I think it's best to just remove it, if it comes up we can just rerun the job.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, removed the whole condition.
|
||
if self.options.env_vars: | ||
bindir = os.path.join(self.package_folder, "bin") | ||
self.output.info("Appending PATH environment variable: {}".format(bindir)) | ||
self.output.info(f"Appending PATH environment variable: {bindir}") | ||
self.env_info.PATH.append(bindir) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
self.env_info.PATH.append(bindir) | |
self.env_info.PATH.append(bindir) | |
self.buildenv_info.prepend_path("PATH", bindir) | |
self.runenv_info.prepend_path("PATH", bindir) |
Env info is Conan 1.x and will be deprecated in the future. In Conan 2.x you should use runenv or buildenv.For Python I would say both cases are valid because I see python scripts during build time, only to generate C/C++ code, but also I saw some packaged tools that are python scripts too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added these for all the existing variables, as well as a note regarding the old version's removal at some point.
python_root = self.package_folder | ||
if self.options.env_vars: | ||
self.output.info(f"Setting PYTHON_ROOT environment variable: {python_root}") | ||
self.env_info.PYTHON_ROOT = python_root |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
self.env_info.PYTHON_ROOT = python_root | |
self.env_info.PYTHON_ROOT = python_root | |
self.buildenv_info.define_path("PYTHON_ROOT", python_root) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
@uilianries Thanks for the review, I'll do some testing and add the suggestions later today or tomorrow. |
Co-authored-by: Uilian Ries <uilianries@gmail.com>
@uilianries I believe I addressed all the review points. My only (very minor) concern left is regarding the environment variables, I think we may be able to simplify one or more of:
I think it might need more thought, but now it works (for now). I can add it to my TODO issue (that I believe you saw) (rather than try to fix it now) if you agree. For context, currently we have: I also did a bit of research on these variables:
|
This comment has been minimized.
This comment has been minimized.
Conan v1 pipeline ✔️All green in build 12 (
Conan v2 pipeline ✔️
All green in build 12 ( |
@Ahajha Thank you so much for your detailed information! It helps a lot to understand the current state of this PR. At this point I'm comfortable to accept it, I'll only talk to @RubenRBS first, to have a final review, but if is all okay, it should be merged by today. Thank you again for this huge effort, this is one of most tricky recipes in CCI. |
Thanks to everyone involved for helping this along! I learned a lot from working on this PR for sure :) |
I guess the use of cpython from conan may have a limited user base because using conan implies using Python. But it's needed for bootstrapping in the corporate requirements of using approved binary repositories (such as Conan Center). And of course the conan way of building C Python could eventually substitute the less-straightforward build systems, enabling C Python development bootstrapping.
Originally posted by @madebr in #1510 (comment) |
@ilatypov There was discussion about leaving Python 2 support, but we ended up dropping it. That said, I'm more than willing to re-add it if you think there's a use case for it in Conan Center. Regarding the failing test, do you know if this ever worked? Also regarding "The original submission took pains to use conan's dependencies for Python 2" - Is this just saying that Python 2 was originally supported, or that it used Conan dependencies? If the latter, I don't think anything has changed - the recipe still goes to great lengths to use Conan's dependencies. I've seen slow but steady adoption of the cpython package within ConanCenter, mainly in places where Conan's minimum Python version isn't enough. When I started this PR (branching off of a few others), I had a use case of easily switching Python versions within a multi-repo application as an alternative to essentially requiring some containerization. All that said, I'm happy to look into the failing test and re-add Python 2. |
I hijacked this thread that showed amazing collaboration. I did not have concerns about resurrecting conan's Python 2 and, unfortunately, I don't know if the smoke test would work with conan's Python 2. It was my attempt to rely on the previous work that seemed successful in packaging conan's Python with its dependencies. (The Perhaps one day I could learn from this group and submit a useful pull request. |
I'm a little confused as to your exact problem, but I have a guess as to the solution: The |
I am not linking, just using Python from Conan Center. Its smoke test above ( |
Let me clarify - Regardless of what you're doing with the package, on Windows, if I think this is a poor default regardless - I have a PR out to change it. |
It worked for 3.8.12 here, thank you. I am new to conan, so I forgot that Conan Center's binary artifacts are not the ultimate goal of this GitHub project, but only its optimization. The Conan Center's recipes are the goals (important deliverables) of this GitHub project. My building C Python for Windows from source using the available recipe took only minutes and worked great.
P.S. I wish Conan Center |
Specify library name and version: cpython/all
I will be leaving the versions as-is in this PR, as changing them tends to break things, and I want to keep the scope small. A separate PR for that is here: #22599 (depends on this PR)
I believe there is some value in having a 2.7 recipe available, but probably not worth it for the CCI maintainers to deal with. If specifically needed, there is a mostly working 2.7 (and 3.7) version available a few commits back from the end of this branch.
Previously, the packages were not 100% relocatable on *nix. For now I always set
PYTHONHOME
in the test packages, not sure if this is a perfect idea but for now it seems to be a reasonably not-hacky solution.Short paths are enabled. Lots of files in pycache directories are packaged - this is intentional, as they are compiled (bytecode/JIT) versions of all the standard library modules.
Known intermittent issues:
There are many CPython issues/PRs out right now:
Resolves #21357
Resolves #20695
Resolves #19374
Resolves #10808
Resolves #12373 (no project upgrade occurs)
Resolves #8198
Resolves #9890 (was only broken on Linux/Mac. Some other with_xxx options don't work, but that's a separate issue)
Unsure if it fixes this, I test locally on an M2 with apple-clang 15 so similar but not exact: #13900
This should be able to be closed after this, since this is the last recipe using the old
libuuid
recipe: #19084This is a problem with CPython being static by default. In future versions, CPython doesn't even properly support static mode, but it's still annoying that the default configuration is invalid: #9333
Unsure, seems like a CPython problem itself: #8608
This PR is based on the following, and should no longer be needed:
Closes #18064
There was also an attempt to fix the libuuid issue:
Closes #19547