Allow python-dateutil==2.8.1

[packyg]

Describe your idea/feature/enhancement

Update version specification of python-dateutil dependency to allow for version 2.8.1

Proposal

Change the version specification in requirements/base.txt python-dateutil to allow any version compatible with 2.6 (2.6 <= version < 3.0)

# Current
python-dateutil~=2.6, <2.8.1

# Proposed
python-dateutil~=2.6

Additional Details

This is causing unresolvable dependency conflicts in some of our poetry-managed projects. Allowing for all patch versions of 2.8 would solve my particular issue, but it would probably be good to allow up to the next major version.

python-dateutil v2.8.1 was released nearly a year ago (2019-11-03) and appears to only contain bugfixes over 2.8.0

It is unclear why python-dateutil has a specific upper bound on version that is lower than the next major release in the first place. Other dependencies (like PyYAML, click, and Flask) do not have such upper bounds.

[jfuss]

@packyg SAM CLI is not meant to be installed with other packages. If you wish to install with pip, you should be using an venv to isolate the cli from others. If you follow our installers, this is done for you.

Closing as we keep our dependencies locked down in order to keep the build reproducible. Please use an venv is you wish to keep using pip.

[packyg]

Then it's still unclear unclear to me why some dependencies (like PyYAML) are not locked down as much as this one.

And I am using poetry to manage project dependencies, which does in fact use a virtualenv under the hood.

For more context: We have built tooling on top of aws-sam-cli to help us enforce internal standards and best practices, as well as to help with configuration management.

We then import that project into other poetry projects as a dev dependency. The problem arises trying to resolve our production dependencies (which require python-dateutil >= 2.8.1) with our dev dependencies (which transitively includes aws-sam-cli and thus this version of python-dateutil). This causes a dependency conflict that we cannot resolve.

While it would be possible for us to globally install aws-sam-cli, e.g. with brew, that takes away the advantage of using a tool like poetry to manage all of our dependencies in one place.

---

@jfuss The "SAM CLI isn't really a package, don't use pip" answer is antithetical to the open philosophy of the Python community.

If SAM CLI is truly not supposed to be installed with other packages, then it should be taken out of the Python ecosystem and delisted from PyPI.