Skip to content

Update package version number to 2.20.0 to correspond with Release v20#80

Closed
javulticat wants to merge 1 commit intoDataDog:masterfrom
javulticat:master
Closed

Update package version number to 2.20.0 to correspond with Release v20#80
javulticat wants to merge 1 commit intoDataDog:masterfrom
javulticat:master

Conversation

@javulticat
Copy link
Copy Markdown

@javulticat javulticat commented Aug 27, 2020 •
edited
Loading

What does this PR do?

Updates package version number to 2.20.0 to correspond with Release v20

Motivation

I noticed today that pipenv was suddenly encountering errors trying to resolve dependencies for this library:

There are incompatible versions in the resolved dependencies:
  datadog==0.32.0 (from -r /tmp/pipenv1ww874dorequirements/pipenv-lh25x49g-constraints.txt (line 7))
  datadog==0.38.0 (from datadog-lambda==2.19.0->-r /tmp/pipenv1ww874dorequirements/pipenv-lh25x49g-constraints.txt (line 4))

This strange behavior seemed to suggest that package version 2.19.0 had changed in PyPi from the last time I had run pipenv (and tl;dr, this appears to be exactly what happened).

I found that a v20 Release was published today which updated the datadog dependency in datadog-lambda from 0.32.0 to 0.38.0, which aligned with the behavior I was seeing. Upon checking PyPi, there did not seem to be a new release:
image

However, I found that a new py3 wheel for 2.19.0 was uploaded earlier today, which again corresponds to the timing of the v20 Release:
image

This seems to explain the behavior I was seeing, where pipenv when resolving dependencies yesterday (on a py3 project) saw this library's 2.19.0 package requiring datadog==0.32.0, to today it requiring datadog==0.38.0.

As far as this fix, I went and looked at previous releases and noted that they always included an update to the package version number (like here, for v19).

Testing Guidelines

N/A for this change - but just in case, the test suite still passes locally:
image

Additional Notes

I imagine additional steps will need to be taken post-merge to publish version 2.20.0 to PyPi, and revert the 2.19.0 py3 wheel to the correct one.

Types of Changes

  • Bug fix
  • New feature
  • Breaking change
  • Misc (docs, refactoring, dependency upgrade, etc.)

Check all that apply

  • This PR's description is comprehensive
  • This PR contains breaking changes that are documented in the description
  • This PR introduces new APIs or parameters that are documented and unlikely to change in the foreseeable future
  • This PR impacts documentation, and it has been updated (or a ticket has been logged)
  • This PR's changes are covered by the automated tests
  • This PR collects user input/sensitive content into Datadog
  • This PR passes the integration tests (ask a Datadog member to run the tests)

@javulticat javulticat requested a review from a team as a code owner August 27, 2020 00:37
@Czechh
Copy link
Copy Markdown
Contributor

Czechh commented Aug 27, 2020

@javulticat - apologies! We have published a new version with the latest changes https://pypi.org/project/datadog-lambda/2.21.0/ here is the release tag: https://github.com/DataDog/datadog-lambda-python/releases/tag/v21

@javulticat
Copy link
Copy Markdown
Author

javulticat commented Aug 27, 2020

@Czechh great, thanks! FYI, I believe someone installing a pinned dependency of datadog-lambda==2.19.0 on py3 will still unexpectedly be getting newer v20/2.20.0 code currently, as I see on PyPi the py3 wheel for 2.19.0 is still the one from today (rather than the original one from July 23).

@akursar
Copy link
Copy Markdown

akursar commented Aug 27, 2020

Just noticed this after opening #83. Sorry! We have 2.19.0 pinned and are experiencing install failures where we have that pinned along with its prior datadog==0.32.0 dependency. Trying to move to 2.21.0 to mitigate but if the original artifact can be restored (or rebuilt from the v19 git tag ) that would help us and presumably anyone who has 2.19 pinned.

@Czechh
Copy link
Copy Markdown
Contributor

Czechh commented Aug 27, 2020

Hey! @akursar and @javulticat

Thanks for bringing this up! I suggest you upgrade to v21 (v2.21.0)

As for the v19 artifact I'm not sure how that happened as they should be immutable.

@javulticat
Copy link
Copy Markdown
Author

javulticat commented Aug 27, 2020

@Czechh did more digging and I think there is a potential explanation:

If you look at the files available on PyPi for this module for any version pre-2.19.0, you'll see the only two files available are a py2 wheel and the source. Here's a screenshot of 2.18.0 for example:
image

2.19.0, however, is the only version which has three files (a py2 wheel, a py3 wheel, and the source):
image

And 2.21.0 released yesterday, has only a py3 wheel and the source (but no py2 wheel):
image

So, what I suspect happened is that sometime between the original release of 2.19.0 and yesterday, a change was made on your end to publish a py3 wheel instead of a py2 wheel for this module. Then, yesterday, when v20 was accidentally published as 2.19.0, nothing was actually overwritten (as you say, the artifacts should be immutable), but the py3 wheel did not previously exist in PyPi, so it was allowed to be published.

This would explain the behavior @akursar and I have seen, as previously pip likely fell back to using the py2 wheel for py3 installs of 2.19.0, as no py3 wheel was available, but since a py3 wheel became available yesterday, pip began pulling that artifact instead, which, again, seems to actually contain the v20 release instead of the v19 release.

It seems, then, that the solution to this issue would be to delete the py3 wheel of 2.19.0 uploaded yesterday to PyPi. It would be great if this (or something else that otherwise resolves the issue that certain 2.19.0 artifacts no longer contain v19 of this library in PyPi) could be done. Ideally, projects that wish to use 2.19.0 could continue to do so. One of the main benefits of dependency management is being able to create reproducible builds that you know work. That ability is currently broken for clients on 2.19.0, and moving to 2.21.0, while potentially a workaround, isn't truly a solution - after all, there is no guarantee that the updates in 2.21.0 don't contain a bug/regression. For a critical application, I would much rather be able to continue to use the version of a dependency that I know works, than be forced to update to a day-old version where I don't have that confidence.

@tianchu tianchu closed this Nov 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@javulticat @Czechh @akursar @tianchu