Fix #2342, and updates for Poetry 1.2

[glennmatthews]

Closes: #2342

What's Changed

• Poetry 1.2.0 is released now
  • It has an underdocumented behavior change that poetry install --extras ... followed by poetry install (without any --extras) will result in Poetry removing the previously installed extras.
• Change our install of Nautobot itself in the dev image to account for this change
• poetry install --no-dev is deprecated in favor of poetry install --only main, so I've made that change.
• Add poetry cache clear --all PyPI to the final-dev image build, fixing Docker containers should not include a poetry cache #2342 (with a workaround for a couple of Poetry bugs)

[glennmatthews]

Weird, hadolint passes locally. Wonder if I have an old version or something. Will fix when I get time.

[glennmatthews]

Actually it's the other way around - CI is using hadolint 2.7 but a locally built dev image has hadolint 2.10. Fails regardless when I run it locally against the actual branch in question 🤦

[bryanculver]

• Poetry 1.2.0 is released now

  • It has an underdocumented behavior change that poetry install --extras ... followed by poetry install (without any --extras) will result in Poetry removing the previously installed extras.

• Change our install of Nautobot itself in the dev image to account for this change

This seems to be a necessary fix as when we ship a new image we'll probably bring in Poetry 1.2 and plugin's development/testing images won't include the necessary dev dependencies at runtime: https://github.com/nautobot/nautobot-plugin-golden-config/blob/develop/development/Dockerfile#L42

[gsnider2195]

Does the poetry installer at https://install.python-poetry.org/ support constraining the version with >=1.2.0 and if so should we add that constraint as part of this change? I know the installer says it will install the latest version so this may not be an issue?

[glennmatthews]

It does always install the latest version by default. We could (and probably should) constrain it with the --version argument so that it will use a specific version until we intentionally move to a newer one though.

[bryanculver]

It does always install the latest version by default. We could (and probably should) constrain it with the --version argument so that it will use a specific version until we intentionally move to a newer one though.

This is how most plugins are installing Poetry: https://github.com/networktocode/gh-action-setup-poetry-environment/blob/main/action.yml

[glennmatthews]

This is how most plugins are installing Poetry: https://github.com/networktocode/gh-action-setup-poetry-environment/blob/main/action.yml

Sure, though that's a virtualenv workflow, not a Docker workflow.

I've added an explicit --version 1.2.0 to the install-poetry command so that we can migrate to newer versions on our own schedule rather than immediately upon release.

[bryanculver]

Just double checking on the comment above. The installer should install it in a place other than /usr/local but should we enforce this through providing --path or $POETRY_HOME?

[glennmatthews]

--path is for specifying where to find the file to install from, if I'm reading the script right. We could explicitly set POETRY_HOME I suppose but I feel like this is a pretty low risk.

[whitej6]

@bryanculver any chance this can get cherry picked for 1.2 & 1.3 stable releases? Having some "fun" issues with poetry & development containers downstream for 1.2 & 1.3