-
Notifications
You must be signed in to change notification settings - Fork 30
feat: add dockerfile output for Python builds #1242
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
base: main
Are you sure you want to change the base?
Conversation
| # Now to get the latest acceptable one, we can step through all interpreter | ||
| # versions. For the most accurate result, we can query python.org for a | ||
| # list of all versions, but for now we can approximate by stepping down | ||
| # through every minor version from 3.14.0 to 3.0.0 | ||
| for minor in range(14, -1, -1): | ||
| try: | ||
| if Version(f"3.{minor}.0") in version_set: | ||
| return f"3.{minor}.0" | ||
| except InvalidVersion as error: | ||
| logger.debug("Ran into issue converting %s to a version: %s", minor, error) | ||
| return None | ||
| return None |
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 was wondering if this bit might be worth changing as per the code comment. The current way of finding the latest satisfying version is not fine-grained. It might fail on certain constraints as well, for example if we were given the constraint ["==3.11.5"]. It also does not fully use our ability to support arbitrarily specific interpreter versions via rebuilding them. So should I go ahead and find a way to get a list of [major.minor.patch] from python.org and then do as per the code comment?
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.
- Please add an example for this new feature to the
docs/source/pages/tutorials/rebuild_third_party_artifacts.rsttutorial. - Add the
dockerformat to the--output-formatCLI arg description. - Update
docs/source/pages/cli_usage/command_gen_build_spec.rst.
| return os.EX_OK | ||
|
|
||
|
|
||
| def gen_dockerfile(buildspec: BaseBuildSpecDict) -> str: |
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 would be good to refactor this function and move it to a new sub-package for Docker formats, and a module for pypi specifically.
Signed-off-by: Abhinav Pradeep <[email protected]>
Signed-off-by: Abhinav Pradeep <[email protected]>
61a5195 to
853852b
Compare
Signed-off-by: Abhinav Pradeep <[email protected]>
behnazh-w
left a comment
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.
Please add an integration test for the docker package used in the tutorial, and use the tutorial tag. For now, we can just compare the dockerfile output with the expected Dockerfile.
| Rebuilding a Python wheel | ||
| ************************* | ||
|
|
||
| The above workflow can be adopted to generate build specifications for Python wheels, often distributed via PyPi, as well. Consider the purl ``pkg:pypi/[email protected]``. We can run analyze like: |
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.
| The above workflow can be adopted to generate build specifications for Python wheels, often distributed via PyPi, as well. Consider the purl ``pkg:pypi/[email protected]``. We can run analyze like: | |
| The above workflow can be adopted to generate build specifications for Python wheels, often distributed via PyPI, as well. Consider the purl ``pkg:pypi/[email protected]``. We can run analyze like: |
| ./run_macaron.sh analyze -purl pkg:pypi/[email protected] | ||
| As with the Maven example, we can also generate a JSON buildspec if we wish to. For the purposes of this tutorial, we will generate a dockerfile output. To do so, we can run ``gen-build-spec`` with the output format flag set to ``dockerfile`` as below: |
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.
| As with the Maven example, we can also generate a JSON buildspec if we wish to. For the purposes of this tutorial, we will generate a dockerfile output. To do so, we can run ``gen-build-spec`` with the output format flag set to ``dockerfile`` as below: | |
| Similar to the Maven example, it is also possible to generate a JSON buildspec. However, for this tutorial, we will generate a ``dockerfile`` output. To do this, run ``gen-build-spec`` with the ``--output-format`` flag set to ``dockerfile``, as shown below: |
…ion. Signed-off-by: Abhinav Pradeep <[email protected]>
Summary
Adds option "dockerfile" to the --output-format flag for gen-build-spec. For Python packages, it generates a dockerfile built on the
oraclelinux:9image to rebuild the package.Description of changes
build_spec_generator.pyto add functionality to infer the latest Python interpreter version satisfying the packages constraints, and generate a dockerfile that would build that Python interpreter from source. The dockerfile then proceeds to use that built interpreter to build the package itself.