It is still under construction and content may change. Do not rely on the information on this page. This is a raw log of everything that was discussed at the Python Guidelines workshop. I'll apply some formatting to this and move it to a new area to finish it off.
SCL - Collections
- Use it to create a parallel stack.
- What is the advantage over virtualenv: to find out what's on your system, have to consult both rpm and pip SCL can tell you a single system. If you biuld from an rpm then you may know more about what rpms are nstalled. Otherwise you just have a blob.
* Better that you have one-one relationship between what's in SCL and what's on system * You do have knowledge of what files are on the filesystem in the rpm database so that allows certain auditing to take place (whereas virtualenv doesn't). * virtualenv doesn't integrate with people's current tools to deal with rpms.
====
Python Guidelines
Parallel 2 and 3 stack
Explicitly say from __future__ import unicode_literals is almost certainly a bad thing
- Reason: Some things should be the native string type. Attribute names on objects, for instance.
- If you are in the frame of mind that you are reading python2 code, then you may be surprised when a bare literal string returns unicode.
- python2 -bb -- turn off automatic promotion so that you get a warning or an error when you mix bytes and unicode strings.
===
wheel -- new
More feasible to generate spec files automatically given the upstream spec file.
%prep unpack the tarball %build create a wheel -- can just be an unpacked directory
bdist_wheel => setup.py subcommand that can be used to create a wheel
pip wheel --nodeps to build
%install Wheel gets installed onto the system into different FHS compliant dirs
datadir
scriptdir
platlib
purelib
docsdir
pip install wheel --installdir
wheel command from python-wheel might not have --root command but pip does have it so we'd need to use pip to install these.
Wheel creates a "database" (distinfo directory). So we would want to install using the wheel package that we build so that this directory is fully installed so pip knows about everything.
- setup.py install => will only play nice with the distinfo data in certain cases. So most of hte time we want to convert to wheel building.
* If the package can't then: * if it's setuptools then we will emit the correct metadata w/ a special command line flag * if it's not
- pip always uses setuptools to install.
- Upgrading to Metadata 2.0 will be an automatic thing.
- pip2rpm from slavek
- Depend on both pip and setuptools explicitly?
* In guidelines BR both because upstream pip may make this an optional feature and we may or may not put that requirement into pip.
- For automake and other ways of creating packages; we want to install distinfo directory but if the upstream doesn't we aren't losing anything.
- We no longer need egginfo files and dirs (if distinfo is installed)
pip-1.5 due out by end of year.
check: Shebang line on pip itself... if we change that to /usr/bin/python2 will that effect everything that it installs? (Should be but check)
- May need to use some pip command line option to have scripts installed the setup.py script target install.
* python3-pip via guidelines
METADATA-2.0 Be able to answer "This package installs these modules". => timeframe pip-1.6 middle of next year. (Hopefully f22).
- With pip wheel we can use a single directory. No need to copy to a second directory anymore.
- pip wheel (build) will clean the build artifcats automatically.
========
Python3
- Python3 by default:
* Change when PEP394 changes
- Not until 2015 or later
- Shebang lines -- we need to change those to /usr/bin/python2 ==> We should audit and change these after the pip migration as the pip conversion will take care of a lot of these.
- Cost of converting /usr/bin/env to /usr/bin/pythonX has also decreased since we have to review and maintain patches for /usr/bin/python => /usr/bin/pythonX. So we could consider banning /usr/bin/env as well.
- env in shebang line: Will always ignore virtualenv. Means that sysadmin's changes will affect this.
- pip -- get-pip. Will bundle a version of pip. In Fedora we can have python-libs Require: python-pip and use a symlink or something
- Naming: How do we want to name python modules?
- python2-setuptools vs python3-setuptools vs python-setuptools
- New packages -- Two separate packages
- Allows us to tell when to abandon the python2 bindings
- makes it so that python2 and python3 don't have
- New packages -- Two separate packages
- Old packages -- grandfathered in but if the reasons make sense to you then you can split them into separate packages
- Decided that it might not be ideal but we're going to promote both subpackage and dual packages.
- Add conditionals to make with_python2 conditional optional
===
pypy -- realistically if you're using C dependencies you shouldn't be using pypy (ref counting in extensions can cause problems between cpython and emulated)
Byte compiled files will differ but at the source level you could share purelib Some of platlib will work using hte emulated C api.
- Worht a try to have it use the system site-packages that python has....
- pypy using the site-package via a symlink. We release note it as:
This is a technical preview -- many things may not work and we reserve the right for this to go away in the future.
- pypy is 4x faster than cpython for the printrun application.
- Packages can use pypy.