-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Is pulling semver and iso8601 needed? #4698
Labels
Type: Vendored Dependencies
This issue affects vendored dependencies within pipenv.
Comments
befeleme
changed the title
Is pulling semver needed?
Is pulling semver and iso8601needed?
Jul 2, 2021
@befeleme Your assessment makes sense to me, please feel free to open a PR for this. |
matteius
added
the
Type: Vendored Dependencies
This issue affects vendored dependencies within pipenv.
label
Mar 13, 2022
oz123
changed the title
Is pulling semver and iso8601needed?
Is pulling semver and iso8601 needed?
Sep 9, 2022
oz123
added a commit
that referenced
this issue
Sep 9, 2022
yeisonvargasf
pushed a commit
to yeisonvargasf/pipenv
that referenced
this issue
Nov 19, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue description
Is pulling semver and iso8601 needed?
I am going through the list of pipenv dependencies for testing purposes in Fedora.
When looking for ways to invoke functionalities of the vendored libraries I realized, nothing really imports
semver
.pipenv/vendor/distlib
uses some semver matching, but it has no connection to the actual library.semver is imported in
tests/test_artifacts/git/pinax/check.py
where it seems it's isolated from the production code - alongside with github3 or tabulate which are also not vendored. I guess (as I don't know the codebase that much) that wherever the artifacts are used, they are isolated and pull the needed libraries from the internet resources.To check the hypothesis I've removed semver and rerun tests with the same good results as before.
I assume it may be safely removed, but I may have overlooked something.
Another thing is bundling iso8601 which is not used anywhere.
pyparsing.py
usesiso8601_date
andiso8601_datetime
, but they're defined there, not imported from the library. The whole library seems unused and safe to remove.If this line of thoughts is correct, I can send a PR with the changes.
The text was updated successfully, but these errors were encountered: