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
