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. > 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? .joel
