On 2023/06/09 21:35, Joel Knight wrote: > On Tue, May 30, 2023 at 7:06 AM Stuart Henderson <s...@spacehopper.org> wrote: > > > > I've attached an updated py-awscrt tar with what I think is slightly > > better handling of this. It's still a bit ugly but I think not as bad > > and it will pick up new things from cmake.port.mk. > > Thank you. That is indeed much cleaner. > > > Now onto awscliv2 (which I thought was going to be the easy part...) > > > > See https://github.com/aws/aws-cli/issues/4947#issuecomment-586046886 > > #3: they don't want to support a wide range of dependency versions > > #4: they want to use their own python build with a specific openssl version > > #5: they want to be able to include other binaries written in various > > languages > > > > Backing this up, upstream's supported installation method is a zip with > > a bundled copy of Python 3.11, static-linked to their own copy of an > > OpenSSL 1.1.1 release, bundled libbz2 libffi libsqlite3 etc plus various > > Python modules. > > That's what upstream's installer does, yes. That's not what the port > does. The port uses the base Python, libcrypto in base, and picks up > the dependent Python modules from ports. I'm hopeful you're not > influenced to vote -1 for something that isn't part of the port.
Yes, but by going down this route and not making it easily available in pypi is a pretty clear indication of the direction upstream want for their software. I think probably every reason why they don't want it in pypi also applies to OS packaging which has similar/harder constraints on interoperability with versions of Python libraries. At least with a pip/pypi install you can isolate things in a virtualenv. > > As things stand, ignoring awscrt (where keeping in sync with > > awscliv2 is no problem), this would add tight version restrictions > > on the following ports: > > > > devel/py-colorama > > devel/py-dateutil > > devel/py-flit_core > > devel/py-jmespath > > devel/py-prompt_toolkit > > security/py-cryptography > > sysutils/py-distro > > textproc/py-docutils > > textproc/py-ruamel.yaml > > textproc/py-ruamel.yaml.clib > > www/py-urllib3 > > > > This already breaks the port (the current versions of several of those > > deps are not accepted, even in upstream git head). And tight specs > > for those ports, many of which are very common, make it difficult to > > work on general Python ecosystem ports. > > Upstream is getting better as they're hearing from the wider community > that their tight dependency versions are making things painful. As > Antoine said, isn't this something we patch around? > > With all the software in ports, there must be others where upstream > has narrow dependencies. How are they handled? Outside of go and rust (where everything's fetched from different versions at build time to produce a single binary so there are no installed libraries to conflict), most upstream projects are a bit more flexible, and only restrict version specs where they're actually needed rather than just because "other versions might not work". There are some projects which don't do this (homeassistant comes to mind; https://github.com/home-assistant/core/blob/dev/pyproject.toml) but not all that many and they don't usually end up added to official packages on most OS. Tighter version specs on a library which is closely associated with the software aren't usually much of a problem because by their nature they don't get pulled in across the ports tree. But there's no real reason for awscli to care enough about which version of flit_core, distro, colorama, etc are used to prevent it from building/running with others. It does make sense for upstream to only use the specific tested versions with their bundled binary distribution but when they make it as hard requirements into the source distribution too, it means that it's barely usable for pip installs (in virtualenvs only, really, to isolate it from other software) and probably every OS wanting to package it is going to need to patch those away. And really, why should every OS wanting to package it go to the trouble of doing this (and redoing for every/most updates)? So it's no surprise that various OS are sticking to the 1.x branch; that is still more restrictive than many other ports on version specs but it's a lot more self-contained than v2 and the permitted ranges are wide enough not to be such a problem.
