Packaging Python 3.4.0

[Bohuslav Kabrda]

----- Original Message -----
> On Tue, Nov 05, 2013 at 07:29:35AM -0500, Bohuslav Kabrda wrote:
> > Hi all,
> > I started working on updating python3 to 3.4.0. So far, this is only in
> > a private branch "python3.4" in dist-git, since I'll need to get a Change
> > approved for Fedora 21. I already created the Change [1], but I was told
> > that it will get on FESCo schedule when Fedora 21 schedule and future is
> > more clear, so for now I'll just work on Python 3.4.0.
> >
<snip>
> So in my view -- submit the Change! :-)

I already marked it ready for wrangler and I asked jreznik, who told me that the changes should be postponed. I'll try to talk to him again and see if there's any real problem about proposing this Change.

> > As for the current state of Python 3.4 in the dist-git branch:
> > - It still seems a bit unclear what upstream will do with the sha3
> >   implementation (although they will probably keep it), so I didn't rebase
> >   the fips patch yet, there is still plenty of time for that.
> 
> I think Christian outlined what they are going to do with sha3 yesterday
> (but yeah, it depends on what is happening with the sha3 standard so there's
> a bit of uncertainty there still).
> 

Yes, exactly what I mean. We still have plenty of time, so I didn't want to spend possibly unnecessary work on rebasing the fips patch.

> > - pep453 [3] (pip bootstraping) hasn't been implemented yet. The pep also
> >   contains recommendation for distro packagers, so here's what we should
> >   do.
> > -- Make a circular dependency between python3 and python3-pip (ugly, will
> >    require bootstraping with every new Python minor version).
> >
> Do you mean minor version as in the "4" in 3.4 or as in the micro level ("0"
> in 3.4.0)?
> 

Minor as in "4". AFAIK the bytecode format only changes with major and minor version (e.g. from 3.X to 3.Y, but _not_ from 3.X.y to 3.X.z).

> We can get around bootstrapping at minor version revs if pip is only used at
> runtime, not at buildtime.
> 
> We can still get around bootstrapping at micro version if we are careful
> never to include pip's code in the package.  Only figure out where to find
> pip's code.

IMO we will need bootstrapping only for major and minor versions, not for micro versions. In other words, I think we will need bootstrapping only when bytecode format changes.

> > -- Maybe remove the bundled pip (although this goes against the pep) and
> > use python3-pip. E.g. everything would work as expected, but under the
> > wraps, python3-pip package would be used. So when doing security updates,
> > we'd just fix python3-pip. It is however true that if Fedora's pip would
> > be different from the upstream bundled one, users may experience some
> > behaviour differencies. I'd like to hear your opinions on how we should
> > approach this.
> >
<snip>
> I'm wondering if we could do a little better.  Instead of keeping around two
> copies of all this software on the system, if we can reconstruct a wheel zip
> (or possibly just copy the files in) from the wheel metadata and files on
> the system.   I know that sysadmins and developers will hotfix software on
> the system for issues that they care about.  Having those changes propogate
> to newly installed venvs seems like a better plan than having the venvs get
> the old copies that were built at rpm build time.
> 

Hmm, interesting idea. Once Python 3.4 test suite passes for me and Python is at Beta, I'll try to look into this :)
The way that Nick is proposing in the other mail ("just copy files into the venv based on the pip and setuptools RECORD files") seems the best to me, I'll try to pursue this solution.

> -Toshio

Thanks a lot,
Slavek.