Re: Python EGG guidelines need updating
On 9 December 2016 at 04:35, Orion Poplawski wrote:
> Python folks -
>
> The FPC needs your help with cleaning up these guidelines:
>
> https://fedoraproject.org/wiki/Packaging:Python_Eggs
>
> I have a draft here:
>
> https://fedoraproject.org/wiki/PackagingDrafts:Python_Eggs
>
> that makes use of some new %py{2,3}_{build,install}_egg macros.
>
> However, I think a lot more cleanup needs to be done:
>
> - Just remove Why eggs through [edit] Providing Egg Metadata Using Setuptools
> as that is just the standard course now?
The main Python guidelines link out to the Python Eggs page for more
detail, so we probably don't want to just delete these sections
without replacing them something.
Perhaps replaces these first four entries with a single section like:
# Python level metadata for installed components
To provide machine readable metadata regarding the Python components
that are installed, Python projects may generate:
* .egg-info files containing basic metadata regarding the package
(e.g. plain distutils)
* .egg-info directories containing a PKG-INFO file and other metadata
files related to the component (e.g. setuptools, pip)
* .dist-info directories containing a METADATA file and other metadata
files related to the component (e.g. setuptools, pip)
These files are read at runtime by various Python libraries (such as
`pkg_resources`) and thus should be packaged for installation along
with other files provided by the upstream project.
If a project emits both `.egg-info` and `.dist-info`, both sets of
metadata should be packaged (`.dist-info` is the newer standard
format, but not all potential consumers of the data have been
updated to read it)
For more details on the other files these directories may contain,
refer to PEP 376: https://www.python.org/dev/peps/pep-0376/
> - Make __requires__='MODULE[VERSIONINFO]' the recommended way to require a
> version as setuptools seems to officially support this?
Indeed, this is a documented feature now:
http://setuptools.readthedocs.io/en/latest/pkg_resources.html?highlight=__requires__#workingset-objects
(Jason's less opposed to it than PJE used to be)
We need to use it in Fedora over pkg_resources.requires() because the
latter can encounter version conflicts when there's a default version
installed directly into site-packages (also documented now at the
above link and in the Python packaging guide:
https://packaging.python.org/multi_version_install/ ).
While this mostly works reliably, we may want to alert folks to this
highly confusing bug that I believe can still be triggered in some
cases: https://github.com/pypa/setuptools/issues/6
> - Drop Egg "Features" to avoid
This could be changed to "Avoid easy_install", since build scripts
should use the relevant install macros.
> - Need updated links, or just drop them?
Updated, I think, with references to:
* https://packaging.python.org/specifications/#recording-installed-distributions
* http://setuptools.readthedocs.io/en/latest/setuptools.html
* https://packaging.python.org/multi_version_install/
* https://packaging.python.org/wheel_egg/
* https://packaging.python.org/pip_easy_install/
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Making sudo pip Safe
On 10 December 2016 at 03:09, Orion Poplawski wrote: > Debian deals with this by having dist-packages > (https://wiki.debian.org/Python). Is this not worth adopting? This would be my main question as well, as tinkering with sys.prefix can have a host of unintended side effects. As far as I can see, the two main relevant pieces of the Debian solution are to: 1. Patch `site.getsitepackages()` to put a `/usr/local` path first: >>> import site >>> site.getsitepackages() ['/usr/local/lib/python3.4/dist-packages', '/usr/lib/python3/dist-packages', '/usr/lib/python3.4/dist-packages', '/usr/lib/dist-python'] 2. Patch the system level installation tools to support `--install-layout=deb`. We can ignore the site-packages -> dist-packages rename (as we're not worried about the "custom builds might pick up system packages on sys.path" concern that addresses), but the other two aspects should be something Fedora can adapt (although the exact spelling of the "I am building a Fedora system package" aspect may be quite different). I do like the notion that `system-python` won't see any additions made to `/usr/local`, just as it won't see any `--user` level installations. The other point I'd also raise is that yes, the *initial implementation* of "/usr/bin/system-python" will share sys.path with "/usr/bin/python3", and hence transparently pick up the full standard library if the latter is installed. However, given the work going on with Fedora modularity, I don't think we want to assume that that's necessarily *always* going to be the case - for example, we may some day be able to make "/usr/bin/python" and "/usr/bin/python3" end-user configurable (so sysadmins can choose their own "default Python") without risking any harm to core system utilities written in Python. Cheers, Nick. P.S. For folks wondering what the problem with "--user" is on Debian/Ubuntu, as far as I know it's mainly the fact that "~/.local/bin" isn't on PATH by default, so scripts installed via "--user" aren't automatically available. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Making sudo pip Safe
On Sat, Dec 10, 2016 at 8:10 AM, Nick Coghlan wrote: > On 10 December 2016 at 03:09, Orion Poplawski wrote: >> Debian deals with this by having dist-packages >> (https://wiki.debian.org/Python). Is this not worth adopting? > > This would be my main question as well, as tinkering with sys.prefix > can have a host of unintended side effects. As far as I can see, the > two main relevant pieces of the Debian solution are to: > > 1. Patch `site.getsitepackages()` to put a `/usr/local` path first: > > >>> import site > >>> site.getsitepackages() > ['/usr/local/lib/python3.4/dist-packages', > '/usr/lib/python3/dist-packages', '/usr/lib/python3.4/dist-packages', > '/usr/lib/dist-python'] > > 2. Patch the system level installation tools to support > `--install-layout=deb`. > > We can ignore the site-packages -> dist-packages rename (as we're not > worried about the "custom builds might pick up system packages on > sys.path" concern that addresses), but the other two aspects should be > something Fedora can adapt (although the exact spelling of the "I am > building a Fedora system package" aspect may be quite different). > If setuptools setup.py had something along the lines of a "--sys-install" switch that would force the installation to /usr rather than /usr/local, I could see us easily adapting our macros to just do that all the time. It might even be something that the Debian guys would switch to, as the main concern they have is ensuring that collisions don't occur. Then if without this switch, pip and other things would default to installing to /usr/local when do you do sudo pip install, I could see this working fairly well. -- 真実はいつも一つ！/ Always, there's only one truth! ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Python 3.6, Fedora, and the "C" locale
Hi folks, One of the minor irritations with running Python 3 applications in Fedora containers is that those containers still default to the "C" local by default - you have to force "C.UTF-8" or "en_US.UTF-8" in order to tell Python that it should use UTF-8 for communicating with system interfaces. However, since 3.5, the CPython start-up sequence has treated claims from the OS that it should use ASCII more skeptically, and enabled the "surrogateescape" error handling by default on the standard streams. Along similar lines, what do folks think of the idea of patching Python 3.6 in Fedora to assume UTF-8 if it's told that it should use ASCII to communicate with the OS? That changes the failure mode from "interface problems happen any time you fail to configure your locale correctly" to "interface problems happen any time you fail to configure your locale correctly *and* your default locale uses an encoding other than UTF-8". That latter case then further breaks down into the following two situations: - you use an ASCII-incompatible encoding like Shift-JIS or GB-18030, in which case the old POSIX default of ASCII was already broken, and the surrogateescape workaround in 3.5 probably didn't help much - you use an ASCII-compatible encoding like koi8-r, which means the surrogateescape workaround in 3.5 probably helped a bit, but libraries like `click` would still have complained and refused to run So I think doing this would be a nice usability improvement for users of the system Python 3 installation on Fedora. I also have an upstream motive for suggesting this, though: if we do this in the more constrained environment of "Fedora users" and it doesn't break the world, then that will help build a case for making it the default upstream behaviour in Python 3.7. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Making sudo pip Safe
> On Dec 10, 2016, at 8:10 AM, Nick Coghlan wrote: > > P.S. For folks wondering what the problem with "--user" is on > Debian/Ubuntu, as far as I know it's mainly the fact that > "~/.local/bin" isn't on PATH by default, so scripts installed via > "--user" aren't automatically available. FWIW, I think Nathaniel? got the uh, Bash? Maintainers on Debian to add it to the default skel for users. — Donald Stufft ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Python 3.6, Fedora, and the "C" locale
On Sat, Dec 10, 2016 at 11:56:44PM +1000, Nick Coghlan wrote: > Along similar lines, what do folks think of the idea of patching > Python 3.6 in Fedora to assume UTF-8 if it's told that it should use > ASCII to communicate with the OS? +1 Non-utf8 environments are nowadays a rarity, OTOH misconfigured installations which do support utf8 but are just missing an env var are rather common (e.g. mock). Zbyszek ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Python 3.6, Fedora, and the "C" locale
On Sat, Dec 10, 2016 at 3:40 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Dec 10, 2016 at 11:56:44PM +1000, Nick Coghlan wrote: >> Along similar lines, what do folks think of the idea of patching >> Python 3.6 in Fedora to assume UTF-8 if it's told that it should use >> ASCII to communicate with the OS? > +1 > > Non-utf8 environments are nowadays a rarity, OTOH misconfigured > installations which do support utf8 but are just missing an env var > are rather common (e.g. mock). > Why aren't we fixing Fedora Cloud/Atomic and the container images to be C.UTF-8 instead of just plain C, then? -- 真実はいつも一つ！/ Always, there's only one truth! ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Python 3.6, Fedora, and the "C" locale
On Sat, Dec 10, 2016 at 05:41:45PM -0500, Neal Gompa wrote: > On Sat, Dec 10, 2016 at 3:40 PM, Zbigniew Jędrzejewski-Szmek > wrote: > > On Sat, Dec 10, 2016 at 11:56:44PM +1000, Nick Coghlan wrote: > >> Along similar lines, what do folks think of the idea of patching > >> Python 3.6 in Fedora to assume UTF-8 if it's told that it should use > >> ASCII to communicate with the OS? > > +1 > > > > Non-utf8 environments are nowadays a rarity, OTOH misconfigured > > installations which do support utf8 but are just missing an env var > > are rather common (e.g. mock). > > Why aren't we fixing Fedora Cloud/Atomic and the container images to > be C.UTF-8 instead of just plain C, then? It's a game of whack-a-mole. You can always fix that place you just noticed where it's missing, but then a few days later it's in another place. Not saying that we should be initializing the locale properly, but rather than we can do both independently. Zbyszek ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
