Stopped working on MacOS 10.15.7

[laurencelundblade]

I know this is an old version of MacOS, but I was successfully building my I-d a few months ago. I don't think it was anything that I changed on my system. Now that the area director has finished review of my draft, I can't build it.

The trouble seems to be with lxml. Maybe lxml no longer supports MacOS 10.15.7? See below.

I have tried to install lxml directly, but that seems complicated.

Appreciate any ideas you might have, but understand that there may be nothing possible for you to do.

Thank you kindly,

LL

(I find all the auto-install that happens here very frightening because I have no control to prevent breakage like this and debugging this could take days)

Building wheels for collected packages: lxml
  Building wheel for lxml (setup.py) ... error
   ...
xcrun -sdk macosx clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -iwithsysroot/System/Library/Frameworks/System.framework/PrivateHeaders -iwithsysroot/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/Headers -arch arm64 -arch x86_64 -DCYTHON_CLINE_IN_TRACEBACK=0 -I/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include -Isrc -Isrc/lxml/includes -I/Users/lgl/IETF/EAT/eat-drafts/9393/lib/.venv/include -I/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/include/python3.8 -c src/lxml/etree.c -o build/temp.macosx-10.14.6-x86_64-cpython-38/src/lxml/etree.o -w -flat_namespace
      In file included from src/lxml/etree.c:96:
      In file included from /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/include/python3.8/Python.h:11:
      In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/limits.h:63:
      /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/cdefs.h:807:2: error: Unsupported architecture

[martinthomson]

This issue belongs to xml2rfc. I suggest you take it there.

[laurencelundblade]

Is there some way I could make I-d template point to an older version of xml2rfc in GitHub when it does it's auto-install?

Thanks for the quick response.

[martinthomson]

If you manually edit requirements.txt, you might be able to set a version there. That will also have the effect of disabling updates for the stuff in this repository, which you might not want.

There is probably some git tweaking you can do to avoid that, like checking the change in and then adding git config pull.ff false, but I won't attest to the robustness of that approach. Essentially, you'd be on your own there.

[laurencelundblade]

Hi Martin, thanks for the responses.

Permanently fixing to a version is very much what I want. When I start authoring an I-D I want to pick the version and stick with it to know I can always build my document. I'm super conservative with using all the fancy features supported to try to avoid breakage. I half-tempted to ask for this kind of permanent fixing to a version as a feature. It's kind of a normal thing for SW to do. I control which version the C compiler I use, my word processor and such.

You are responding nicely here, but I am on my own here! I'm stuck debugging python and pip and such. I wrote a few lines of Python once, but it's not what I'm into.

I suspect the problem is the combo of versions of lxml, Xcode and MacOS. Probably not even an xml2rfc problem. It was probably lxml that changed, because nothing else did. That probably means it is neither the fault of I-d-template or of xml2rfc. Probably the only thing you could do is a lot of work so that copies of all dependencies are bound into a giant bundle or such. Docker?

I've also contacted the xml2rfc folks, and they are responding, but it seems unlikely to end in an easy solution.

[martinthomson]

In case you want to pursue the docker image path, there are some images in this repository you can use.

As far as this repository goes, the git submodule command can be used to bind to a specific version of this code. That won't help directly, as it isn't transitive: requirements.txt is still evergreen. Forking might give you the ability to tie things down though.

Personally, I'm very much of the view that evergreen is essential, but that's for software that has to deal with being on a hostile network and I appreciate that that approach puts you onto a treadmill.

[laurencelundblade]

I upgraded MacOS and I am OK now.