Tip for people using `awscli2`


I’ve just hit an issue with awscli2:

> aws -v
ImportError: cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_'

The issue does not depend on flox and is documented for example here.

There is a workaround which consists in unsetting the PYTHONPATH variable before running aws. This can be done in the [hook] section of the environment:

script = """
   alias aws="unset PYTHONPATH; aws"

I was a bit shocked to realize that even with nix, packages still find ways to badly interact with each other. Would it be possible to have fully isolated packages with flox and avoid this kind of issue?

we are working on providing a way to full isolate packages with a pkg-group attribute in your manifest. we are also considering a mode for flox where imperitive commands (like install) automatically can do either behavior (today’s behavior of all packages go into the same group or, alternatively, a separate pkg-group for each package for better isolation)

1 Like

Woot, that will be great!

I use awscli2 from Flox:

λ flox list --out-path | grep awscli
stable.nixpkgs-flox.awscli2 /nix/store/y8qprb05wn6y1r6p29bygr48zd9hvm3j-awscli2-2.15.0

no issues whatsoever

Nix replaces standard ways of doing this with it’s own:

Each binary is a wrapper that manually adds only specific packages into sys.path of each binary when executing. This provides modularity and ensures that packages uses specific dependencies.

However, doing this would require removing PYTHONPATH, which you did manually. And with removing it, you cannot do development in Python for your scripts normally, without converting your package into Nix too. So PYTHONPATH is available in the system, causing this clash. The problem actually is in the wrapper itself - it adds specific libraries instead of setting sys.path to be a static set. It does that because Python’s sys.path also has system-wide packages from Python itself, but it’s an incorrect method combined with PYTHONPATH having all packages from all modules too.

1 Like