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
Add ordered-set-stubs installation instructions #42
Conversation
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 don't understand how this typing ecosystem is supposed to work anymore. And of course I can't test whether it does the right thing in your IDE or your CI or whatever needs these types, and that seems to be the issue here.
If this is something I should really be doing to such a simple library as ordered-set, then there would have to be some well-established guide I can follow about how to test and integrate .pyi files. But the integration pattern where I release new versions to PyPI and then you tell me if they worked isn't sustainable.
If you're in a hurry to cope with some policy that requires type checks to pass, I suggest forking ordered-set.
setup.py
Outdated
@@ -15,8 +16,11 @@ | |||
long_description_content_type='text/markdown', | |||
py_modules=['ordered_set'], | |||
package_data={'': ['MIT-LICENSE']}, | |||
data_files=(('lib/python{}.{}/site-packages'.format(*sys.version_info[:2]), ['ordered_set.pyi']), |
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 doesn't look right to me.
I tried searching for things related to this. I found python/typing#84 (comment), where lines like this appear to be a hack that MyPy developers were using to experiment with installable types.
The "ideal UX for library authors" suggests that this should be unnecessary, that .pyi files should just be pip installed the same way as .py files. If this doesn't work yet, then I think that is something for pip and mypy to work out between them, instead of every package maintainer adding fragile-looking path acrobatics to their library. On the other hand, if this really is just boilerplate that the Python devs promise will keep working, just point me to the guide.
ordered_set.py
Outdated
T = TypeVar('T') | ||
|
||
|
||
class OrderedSet(MutableSet[T], Sequence[T]): |
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.
Is there no way to specify that an OrderedSet[T] is a Sequence[T] in the .pyi file? We have to import typing
in the code itself?
If so, what is the point of .pyi files? I thought the entire goal was that .pyi files could be written separately to describe a library that already exists.
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.
Is there no way to specify that an OrderedSet[T] is a Sequence[T] in the .pyi file? We have to import
typing
in the code itself?
I specified this in the .pyi
file, but that's not enough: the .pyi
file is not executed, but the .py
file is, and when you run OrderedSet[int]
, for example, python looks at the OrderedSet
definition in the .py
file. Moreover, I don't see anything bad in using the typing
library. It's just a tiny dependency, which you will drop when the time comes and old python will be not longer supported.
If so, what is the point of .pyi files? I thought the entire goal was that .pyi files could be written separately to describe a library that already exists.
The point of .pyi
files is that you can describe types with convenient type annotations convention even if you use old python. I don't see the point to annotate existing library, that supports only python > 3.5, that way.
I found the PEP that discusses typing stubs. It does not recommend the path tricks that appear in this PR. Instead, it recommends adding a marker file named It also seems possible that you could create an |
Thank you. I didn't notice myself. Fixed it, see the last commit.
|
Importing I'm fine with having the types in the package, as long as they can go in the .pyi file. The main reason I bring up the ability to make a separate package is as an existence proof: clearly you can add types in .pyi files without changing the .py code, because people add types for code they don't control at all. |
@rspeer, I asked the question on stackoverflow. Let's see if somebody has the solution for this. |
Well, that's simple enough. Except, don't you need to actually add an empty file named |
I think you are right. My bad. The problem is that despite I did it, it didn't work out: |
It seems likely to me that distutils doesn't know anything about If SO doesn't get you a reply, perhaps raise an issue on the MyPy issue tracker. From the state of MyPy discussion, it seems likely to me that support for packaging types is still immature, despite the PEP. They might actually do this only through the |
I've tried a couple of variations on this in my Python 3.7 environment that I'm certain is up to date with setuptools and stuff. I can get the .pyi file included in the sdist package if I put it in MANIFEST.in, but it still doesn't seem to get installed anywhere. (I don't know where to look, though. Where even is |
Oh, I figured it out. In PEP 561, I found: "This PEP does not support distributing typing information as part of module-only distributions. The code should be refactored into a package-based distribution and indicate that the package supports typing as described above." I also found the trick you were doing before with the explicit |
Hi, I would not recommend relying on Instead, I'd recommend that you create an |
I suppose so. Maybe the stubs can be a real package even when Thank you again for all the effort you're putting into this, and I wish I could determine more reliably what the right way to do things is. |
@rspeer, OK. I suppose I will do it at weekend. |
@rspeer, I've created |
Excellent, thanks! |
Hooray!
…On Wed, Oct 10, 2018, 21:03 Robyn Speer ***@***.***> wrote:
Excellent, thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#42 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADSjIw4V9vRgAgpU2HbDB-rarW03UEDpks5ujjZcgaJpZM4Wqxpz>
.
|
I have found that:
ordered_set.pyi
file is not copied toordered_set
package.OrderedSet[str]
, for example, gives an error.This PR fixes both.
After the merge, please release. Sorry, I didn't notice for the first time.