-
Notifications
You must be signed in to change notification settings - Fork 23.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
Modernize install #76021
Modernize install #76021
Conversation
setup.cfg
Outdated
@@ -0,0 +1,54 @@ | |||
# Minimum target setuptools 39.0.1 to cover Ubuntu 18.04 |
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.
Can you explain this comment (and the one below it) further?
Are they related to our minimum setuptools
version in the Makefile
?
Line 186 in b121142
$(PYTHON) -c 'import setuptools, sys; sys.exit(int(not (tuple(map(int, setuptools.__version__.split("."))) > (39, 2, 0))))' |
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.
That entry in the Makefile
is interesting, I didn't even know it was there. I added this comment operating off of the assumption that the community team will package ansible-core
2.13 for Ubuntu 18.04. However, Ubuntu 18.04 only has setuptools
39.0.1. Which means that I needed to target the minimum feature level to what was accessible in 39.0.1
.
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.
Given that this check is here, can we raise our minimum setuptools
version?
The |
name = ansible-core | ||
version = attr: lib.ansible.release.__version__ | ||
description = Radically simple IT automation | ||
long_description = file: README.rst |
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.
Wild idea: why not add some changelog pointers too?
long_description = file: README.rst | |
long_description = file: README.rst, docs/docsite/rst/porting_guides/porting_guide_core_2.13.rst |
Here's an example project doing this: https://pypi.org/project/attrs/#release-information.
4c3ce6c
to
febdd6c
Compare
dist = distribution('ansible-core') | ||
ep_map = {ep.name: ep for ep in dist.entry_points if ep.group == 'console_scripts'} | ||
|
||
parser = argparse.ArgumentParser(prog='python -m ansible', add_help=False) |
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's not going to always be python
. Sometimes it's python3.10
or python3
or ./path/to/venv/bin/python
.
Maybe it could be something along the lines of
parser = argparse.ArgumentParser(prog='python -m ansible', add_help=False) | |
mod_path = Path(__file__) | |
if mod_path.parts[-1] == '__main__.py': | |
mod_path = f'{sys.executable} -m {(mod_path / "..").resolve().parts[-1]}' | |
parser = argparse.ArgumentParser(prog=str(mod_path), add_help=False) |
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.
meh, it's close enough for me. I'd rather not do gymnastics to figure it out.
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'm not going to push for this. Just remembered one case where pip
(with a Fedora patch on top) used __main__.py
in their output and that was rather confusing.
display = Display() | ||
except Exception as e: | ||
print('ERROR: %s' % e, file=sys.stderr) | ||
sys.exit(5) |
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.
Mind putting this magic value into a constant with a descriptive name?
I'd read much better if it was
sys.exit(5) | |
sys.exit(RC_CLI_INIT_FAILURE) |
or something like that.
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 might defer this to another PR later. I don't necessarily exactly know what rc 5 is supposed to indicate. I just copied it from the previous file. I know there is another PR attempting to better define the exit codes.
base_dir="$(dirname "$(dirname "$(dirname "$(dirname "${OUTPUT_DIR}")")")")" | ||
bin_dir="$(dirname "$(command -v pip)")" | ||
|
||
# deps are already installed, using --no-deps to avoid re-installing them |
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.
They won't be reinstalled without --no-deps
either, unless there are conflicts or you also add -U
. The only thing this will skip is the dependency tree resolution.
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.
Yeah, the problem we ran into, is that the venv is created with --system-site-packages
and even though they are accessible that way, pip
still tries to install them into the venv, as if they weren't satisfied. The problem comes about with crazy dances we have to do in code to install the correct version of cryptography.
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.
ouch
bin_dir="$(dirname "$(command -v pip)")" | ||
|
||
# deps are already installed, using --no-deps to avoid re-installing them | ||
pip install "${base_dir}" --disable-pip-version-check --no-deps |
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.
Consider using pip wheel
or python -m build
to create a dist and then pip install
that, instead of installing from dir which is not something the end-users will trigger in the wild.
Co-authored-by: Sviatoslav Sydorenko <wk.cvs.github@sydorenko.org.ua>
# * https://github.com/pypa/setuptools/commit/bd110264 | ||
from distutils.command.build_scripts import build_scripts as BuildScripts | ||
from distutils.command.sdist import sdist as SDist | ||
install_requires = (here / 'requirements.txt').read_text(encoding='utf-8').splitlines() |
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.
FYI, IIRC this is one of the things that would break in a zipfile where you'd have to move to pkgutil.get_data or some other managed package data access...
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.
In the modern world, it'd be https://importlib-resources.rtfd.io/en/latest/using.html#file-system-or-zip-file
SUMMARY
This PR:
setup.py
, addition of setup.cfgdistutils
insetup.py
entry_points
console_scripts
instead of symlinked bin filesdeprecatesansible.module_utils.ansible_release
This is done to largely remove symlinks withinlib/
, although it needed to be done anywayISSUE TYPE
COMPONENT NAME
setup.cfg
ADDITIONAL INFORMATION
TODO: