This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: rebuilding python pip from source
On 2019-03-04 16:07, Doug Henderson wrote:
> On Mon, 4 Mar 2019 at 12:00, Yaakov Selkowitz wrote:
>> 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:
>> 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.
> Hopefully I can get by with your releases, rather than tracking the
> HEAD. Do you have tags that correspond to the releases? I don't know
> how to tell Github to show tags, if it can.
Left button dropdowns for branches or tags or git tag --list command.
>> 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:
> Yes, this is what I want to understand.
>> 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.
> Thanks. This will help a lot, if I understand it correctly.
> It looks like you do not clear your build directories using 'cygport
> finish' after uploading new/changed packages, so a lot of
> inter-package state is retained in your /usr/src tree. Is this
> correct? Or am I misunderstanding the recipe you show above.
> In step 2, should I be executing the just built executable:
> ../inst/usr/bin/python3.7m.exe ? That seems to work.
> In step 3, I get:
> $ pwd
> /usr/src/python-wheel-0.32.3-1.src
> $ cygport python-wheel.cygport prep
> *** ERROR: python27-pip is required to build this package
> I don't understand how to get past this point.
> Am I calling cygport correctly at this point?
> Do I need any environment variables?
> What does this mean, besides the obvious? What kind of thing is
> `python27-pip' and where should it be? Is it looking in a wheel file
> somewhere? In the /usr/src/python37-3.7.2-1.src tree? In the
> /usr/src/python2-2.7.15-1.src tree? Do I need to cygport pe & compile
> & install and then install pip2 in that local install tree? And
> likewise for each of Python 3.4, 3.5, 3.6? Or do these versions of pip
> need to be installed into my system via setup.exe?
> Do I need to study Gentoo's portage to get a better understanding of
> how cygport works?
> Sorry about all the questions. Perhaps I'm trying to move ahead too
> quickly, without poring through the source for cygport. I've found
> the document at https://cygwinports.github.io/cygport/cygport_in.html
> to be a bit sparse in some important places (and I know exactly how
> this kind of documentation gets created, as I've done it myself a time
> or two).
Symlink /usr/share/doc/cygport/html/manual/index.html -> cyport-doc, also alias
opening with cygstart, also bookmark in your browser, and start reading; browse
around in /usr/share/cygport/cygclass and that neighbourhood.
When third party builds have problems under Cygwin, try using cygport to solve
some of the problems, often more easily than hacking the build directly,
although that can't always be avoided, in which case those patches are
candidates for submitting upstream.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.