rebuilding python pip from source

[Yaakov Selkowitz]

On Mon, 2019-03-04 at 11:09 -0700, Doug Henderson wrote:
> On Mon, 4 Mar 2019 at 09:39, Yaakov Selkowitz <> wrote:
> > On Mon, 2019-03-04 at 04:57 -0700, Doug Henderson wrote:
> > > I am trying to rebuild the python37-pip package from source.
> > > Checking source in setup gives me /usr/src/python-pip-19.0.2-1.src/
> > > When I try to build the package I get an error:
> > > 
> > >     $ cygport python-pip.cygport all
> > >     *** ERROR: python27-pip is required to build this package
> > > 
> > > Initially I got errors saying python36-pip, etc. were required, so I
> > > installed the binary and source packages for them, but there is no
> > > python27-pip or python2-pip package available to install.
> > 
> > There is: https://cygwin.com/packages/x86_64/python27-pip/
> 
> I have that package installed. I want to be able to compile it from
> source, as a small step towards my ultimate goal.

To be clear, to build the python-pip package from source with the
included .cygport file, you still need to have pythonXY-pip installed.

> > > Ultimately I intend to completely rebuild from source both Python 2.7 and 3.7
> > > and all the other packages named "^python.*".
> > 
> > To what end?
> 
> Because that is a right granted to me by the open source license under
> which some source code is released. Perhaps not explicitly by the
> Python and cygwin licences, but as an implied ability.
> 
> What is the point of having a source package but to be able to rebuild
> the binary package. For me, it is more a learning process than
> anything else.

Fair enough, but keep in mind that Cygwin is a binary distribution, not
a BLFS manual.

> I suspect that the Python build process requires some manual steps in
> addition to perhaps running cygport in small step, or even editing
> the.cygport file between those steps, that are not obvious from
> examining the source package. I suspect there is a recipe that you use
> every time you build a new Python release. I hope you can share that
> with me.

The .cygport file together with the cygport program in whatever state
it is at the time of building (keep in mind, as the primary author
thereof, I always use git master) is exactly how the package is built,
and how it can be rebuilt.

Now, if you're asking about how I bootstrap python-pip's build-time
requirement on pip for a new X.Y version of Python (wrt the brand new
scheme where each is supported concurrently), that would be:

1. build pythonXY with cygport and install locally
2. pythonX.Y -m ensurepip --altinstall
3. rebuild/update python-wheel with cygport and install pythonXY-wheel
locally
4. rebuild/update python-setuptools with cygport and install pythonXY-
setuptools locally
5. rebuild/update python-pip with cygport and install pythonXY-pip
locally
6. remove any cruft from step 2.
7. rebuild/update python-virtualenv with cygport

This isn't reflected in the .cygport files because exactly how pip
became present on the system it is irrelevant to the building of the
packages themselves.

> I am thinking about porting some other packages to cygwin, and Python
> represents a complex system of packages that appears to make good use
> of cygport. Along the way, I need a better understanding of cygport,
> and how to wrap a provided build system within it.

My Ports repos cover a wide variety of packages from which you may be
able to learn more:

https://github.com/cygwinports/
https://github.com/cygwinports-extras/

Also, the manual is included with the cygport package and is also
available online:

https://cygwinports.github.io/cygport/

--
Yaakov