-
Notifications
You must be signed in to change notification settings - Fork 923
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Instrument Python version metric #7617
Conversation
165ec0b
to
df65fb4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should do the trick at least initially. I think the most interesting question this raises is how many repos actually have multiple python versions defined in different manifest files?
# ecosystems our goal is to extract the user specified versions, so we'll need to do file parsing... so should | ||
# we move this `ecosystem_versions` metrics method to run in the file parser for all ecosystems? Downside is if | ||
# file parsing blows up, this metric isn't emitted, but reality is we have to parse anyway... as we want to know | ||
# the user-specified range of versions, not the version Dependabot chose to run. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm planning to have follow-on PR's that move this to the FileParser
class, but that refactor will require more work, and want this live now so it starts collecting metrics, so I'm going to merge as-is and then clean it up.
# TODO: alternatively this could use `python_requirement_parser.user_specified_requirements` which | ||
# returns an array... which we could flip to return a hash of manifest name => version | ||
# string and then check for min/max versions... today it simply defaults to | ||
# array.first which seems rather arbitrary. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
user_specified_requirements
is a private method, so the best way to do that is move this to FileParser
, but again, we want metrics soon, so ship this first then clean that up.
We want to know what versions of python are required by our users, so this is an initial stab at collecting some data. Ideally we capture the minimum version, the maximum version, and the raw data from each manifest file that allowed us to calculate the min/max... unfortunately this isn't so clean/polished, but we need to start somewhere and even a primitive form of this metric will provide enough information for us to understand the user impact of dropping python 3.6.
26cf1dd
to
96306ed
Compare
5457b6e
to
5f524ed
Compare
We want to know what versions of python are required by our users, so this is an initial stab at collecting some data. Ideally we capture the minimum version, the maximum version, and the raw data from each manifest file that allowed us to calculate the min/max... unfortunately this isn't so clean/polished, but we need to start somewhere and even a primitive form of this metric will provide enough information for us to understand the user impact of dropping python 3.6. --------- Co-authored-by: Tom Christensen <pavera@github.com>
We want to know what versions of python are required by our users, so this is an initial stab at collecting some data.
Ideally we capture the minimum version, the maximum version, and the raw data from each manifest file that allowed us to calculate the min/max... this won't be quite so clean/polished, but we need to start somewhere and even a primitive form of this metric will provide enough information for us to understand the user impact of dropping python 3.6.