my understanding is:

• that V1.x support will continue and be available PyPi
• V2.x will not be available on PyPI but via a binary download from Amazon Currently only Mac/Win/Linux Installers are available
• V2.x uses different auth API which is why I chose awscli2 to avoid confusion if someone upgraded an existing awscli then they would be get authentication failures
• the noflavors was copied. I though this meant just one package using the default Python version so upgrades automatically each time a new Python is made as default. unlike Ansible which has to be deleted and reinstalled each time Python changes

Would you look at my revisions and let me know where improvements can be made.
Thanks

In D35506#805709, @hsw_bitmark.com wrote:

my understanding is:

• that V1.x support will continue and be available PyPi
• V2.x will not be available on PyPI but via a binary download from Amazon Currently only Mac/Win/Linux Installers are available
• V2.x uses different auth API which is why I chose awscli2 to avoid confusion if someone upgraded an existing awscli then they would be get authentication failures
• the noflavors was copied. I though this meant just one package using the default Python version so upgrades automatically each time a new Python is made as default. unlike Ansible which has to be deleted and reinstalled each time Python changes

Would you look at my revisions and let me know where improvements can be made.
Thanks

Thanks for the detail.

Keeping awscli matching the registered PyPI package and name is fine then.

We can switch it over if and when upstream replaces awscli with the 2.x version (or follow whatever it is that they do)

• the noflavors was copied. I though this meant just one package using the default Python version so upgrades automatically each time a new Python is made as default. unlike Ansible which has to be deleted and reinstalled each time Python changes

You correctly describe the behaviour when PKGNAMEPREFIXES dont exist (like this port) and Python default versions change, but there's additional nuance:

• Official package builders only produce a single version of Python ports (using the current default versions) at the moment, but that is a function of there just being a policy not to, and is not a function of noflavor being defined or not. If that policy changed tomorrow, all ports without noflavors would automatically do the right thing and have packaged produced for them, as expected.
• As mentioned in the original reply, noflavors also switches the default expectation of users to be able to choose what Python version they want a package or set of packages to use, a principle of least astonishment (POLA) violation, prevents their ability to choose when to change/upgrade Python versions for their tooling/packaging, and is contrary to the default behaviour and value Python has sought to create for Python on FreeBSD for users.
• noflavors was technically created only as an escape hatch for automatic Ports (not Python specifically) flavour creation. It just so happened that Python ended up being a first and major flavor consumer, so the perception is its a python port thing.

In terms of what we do for these ports now, we have the following to consider:

• noflavors is already defined in awscli, but its existence in that port is not a warrant itself that awscli2 must follow.

• the package name has changed in the past (with and without PYTHON_PGNAMEPREFIX), and removing noflavors from awscli would mean changing it again:

2018-01-02

Affects: users of devel/awscli

Author: bhughes@FreeBSD.org

Reason: 
  The package name for devel/awscli has changed (back) to just awscli.
  The introduction of flavors erroneously caused the awscli package to
  be renamed to py27-awscli.

I would argue the original addition of noflavors was incorrect to begin with, contrary to how the UPDATING message above sounds (that having the prefix was erroneous)

• As this review is for the addition of a new/separate port, there's less of a need to gate or couple the commit of this port, to changes in another port, but again, not removing nofvlaors from awscli isnt itself warrant to include it in awscli2.

• If awscli was landing today with review, noflavors would be questioned and likely not included. With that in mind, its likely in the long-term state for noflavors to be removed from awscli (along with any other port that does that, for that reason as well as the "this is how we package python ports in all but exceptional cases" and "user choice" grounds.

I have updated the Makefiles and patches to latest versions.

The awscli make test is failing because there is a fresh download on an unpatched py-aws-crt during the test build
this causes compilation to fail because __BSD_VISIBLE is not defined adding this to TEST_ENV had no effect.

Since the main branch of https://github.com/aws/s2n-tls contains the required fixes but ttps://github.com/awslabs/aws-crt-python
does not have an updated s2n submodule, I am not sure what to do:

• Just remove the test code
• Or, comment it out with a message to retest when 0.13.14 of the crt is released

I would appreciate any advice on how to proceed with this port.

update with latest version, devel/py-awscrt has been ported by someone else, so remove those files from this revision,
except for the missing LDFLAGS in the devel/py-awscrt/Makefile

for make test I tried patching the tox.ini with a setenv= to set CFLAGS and LDFLAGS to build values suitable for the py-awscrt "wheel" but it fails because of the bug in its setup.py.

The failure occurs during:

* Installing packages in isolated environment... (awscrt>=0.12.4,<=0.13.15, colorama>=0.2.5,<0.4.5, cryptography>=3.3.2,<37.0.0, distro>=1.5.0,<1.7.1, docutils>=0.10,<0.17.2, jmespath>=0.7.1,<1.1.0, prompt-toolkit>=3.0.24,<3.1.0, python-dateutil>=2.1,<3.0.0, ruamel.yaml>=0.15.0,<=0.17.21, urllib3>=1.25.4,<1.27, wcwidth<0.2.0, wheel)

the error being:

ld: error: unknown argument '-fatal_warnings', did you mean '-fatal-warnings'

@hsw_bitmark.com Can you please comment/resolve remaining comments?

I think I have addressed the current Issues, but there more recent versions the most recent is 2.9.22
my port is still on 2.7 branch and I wonder if I should try 2.9 branch to see if that workable first

I have looked at more recent versions up to 2.11.6 and the build system is completely different, basically ./configure + make
and it uses pyinstaller to 5.8 to do the build.

devel/py-pyinstaller is currently PyInstaller-3.5.tar.gz and its PyPi distfile is now all lowercase and appears to have had all the docs remove
so this port would need to be fixed first. Latest dist is: pyinstaller-5.9.tar.gz

Currently:

1. Updated devel/py-pyinstaller to 5.8 and remove all doc build from its Makefile (most other py-* do not seem to have docs)
2. Add new port devel/py-pyinstaller-hooks-contrib (required by awscli 2.11.6)
3. Update devel/py-awscrt to 0.16.13 and patch missing link info
4. Update devel/awscli2 to 2.11.6

The result which is a stand-alone pyinstller system, i.e., all deps in /usr/local/lib/aws-cli

The port has been simplified, and most of the original patched have been removed

• configure need #! fix to use bash since it uses a bash specific read -r -d '' to read multiple lines to a shell variable, FreeBSD /bin/sh does not support this
• since FreeBSD Python is be default built without embedded sqlite3, the py-sqlite3 is an extra dependency for build/run
• all other Python packages are built into the port by PyInstaller