Skip to content
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

Jump to bottom

Allow non-types dependencies #5768

Open
srittau opened this issue Jul 13, 2021 · 1 comment
Open

Allow non-types dependencies #5768

srittau opened this issue Jul 13, 2021 · 1 comment
Labels
project

Comments

@srittau
Copy link
Collaborator

@srittau srittau commented Jul 13, 2021

This was previously discussed in #5618 and came up in #5765. I think the consensus is that we should allow this. This issue is mainly to track this.
srittau added a commit to srittau/typeshed that referenced this issue Jul 13, 2021
@srittau
Allow non-types dependencies
20b5956 
Remove the check in check_consistency that ensures that only other
type packages from typeshed are being depended on. Instead, add an
explanation to CONTRIBUTING that spells out the requirements. This
adds a higher, but reasonable burden on maintainers to check the
dependencies manually.

Part of python#5768
@srittau srittau mentioned this issue Jul 13, 2021
Merged
srittau added a commit that referenced this issue Jul 14, 2021
@srittau
Allow non-types dependencies (#5769)
ad3f0c8 
Remove the check in check_consistency that ensures that only other
type packages from typeshed are being depended on. Instead, add an
explanation to CONTRIBUTING that spells out the requirements. This
adds a higher, but reasonable burden on maintainers to check the
dependencies manually.

Part of #5768
@intgr intgr mentioned this issue Aug 5, 2021
Open
@intgr
Copy link
Contributor

@intgr intgr commented Aug 5, 2021

Copying relevant discussion from #5618 for context:

srittau commented on Jun 18

Not speaking about stubs packages in general, but I think it's reasonable if typeshed packages depend on dependencies of the corresponding upstream package. I.e. if package foo depends on cryptography, it's fine that our foo-types depends on cryptography as well, since it doesn't introduce "new" dependencies. Apart from that we should vet dependencies carefully.

JukkaL commented on Jun 18

I agree with srittau.

I think that it would be sufficient to maintain an allowlist of vetted dependencies. I'd expect that the number of such dependencies will be fairly small, so it shouldn't be much effort to maintain.

Loading

@srittau srittau mentioned this issue Aug 23, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
project
Projects
None yet
Milestone
No milestone
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
@srittau @intgr