Most practical way to install bundle on a desktop?
alexwhittemore opened this issue · comments
I had previously been using blinka and a FT232h to do some circuitpython stuff on my desktop (Mac), so I've got a nice virtualenv set up for that. What I realized is, when I open an actual board's main.py inside VSCode with the virtualenv's interpreter selected, suddenly, since I've got the full CircuitPython infrastructure there, intellisense works great! Having full autocomplete and whatnot is just delightful, and makes developing even directly on the board (almost) completely first-class.
So now the question is, how do I most easily install this library bundle in a CPython environment? I'd probably be fine with pip for each one individually, BUT it looks like some aren't in PyPi, specifically adafruit_debouncer. Judging by the length of the "adafruit-circuitpython-xxx" list in Pip vs here, I imagine debouncer isn't alone? And I suppose there are probably a few libraries that don't make any sense on a desktop, but would still be beneficial to have for this IDE/intellisense reason.
For now, I guess I'll have to clone it locally, add the setup.py, and install that way.
Thoughts?
@alexwhittemore It's great to hear that Intellisense is working well for you with CircuitPython with the libraries installed!
You are correct that there are a number of libraries that are not on PyPI for various reasons - e.g. they are helper libraries or they don't work in a CPython environment, etc. This list provides a quick visual scan of the libraries on PyPI (e.g. with (PyPI) after the library name), and those that are not (e.g. nothing following the library name).
Debouncer was deliberately excluded, but I've asked someone to test it in CPython and they verified it worked, so I'll be adding it to PyPI. I realise this doesn't solve the actual issue at hand, but was still worth looking into.
Regarding the real purpose of your question, I will need to give this some consideration. There are a couple of possibilities to make this simpler, and I'd like to sort out which one makes the most sense. There must be an easier way than installing them each individually. As for the libraries not on PyPI, if I can nail down a script or some other option that pulls down those libraries and puts the .py files into an appropriate location, that may be a possibility. I will get back to you soon.
Does pip support meta packages that just have a long list of dependencies? It still shouldn't include packages that won't work in CPython though. Maybe we can autogenerate stub packages for those though?
We also have a stub package for the native APIs but it isn't currently automatically released to pypi.
I realise this doesn't solve the actual issue at hand, but was still worth looking into.
In point of fact, it totally solves MY issue - I was just trying to generalize since the general case might actually be useful to others :)
I definitely don't mind the idea of a sort of bandit-install, since this IS kind of an edge case of wanting to "install" stuff we know won't/cant work for the secondary reason of intellisense. And for that matter, having not tried it, maybe there ARE reasons it's a bad idea? Like errors that will come up in intellisense because the underlying libraries don't work? But I don't know of any yet.
@tannewt I honestly don't know the answer or really even understand the questions that well - I've always kind of been mystified as to how exactly pip and the pypi release cycle works, having never pushed a package up there.
Ultimately I do agree that there probably ought to be some meaningful distinction between "what gets installed here and can actually be used on this platform" vs "what we're installing strictly as a tooling reference to work on the embedded side." Being able to have full autocomplete and library introspection and all the rest of it only one ctrl-s away from the hardware is just too nice an experience not to some up with something, though.
@alexwhittemore I created a self-assigned issue on the Debouncer library to get it onto PyPI. Expect to see it there soon, likely tomorrow.
@alexwhittemore Debouncer is on PyPI. I'm leaving this issue open as it is still worth considering.
If I come up with any good solutions I'll look into them and let y'all know. Thank you the mostest!
did you try the circuitpython extension on vscode ?
https://github.com/joedevivo/vscode-circuitpython
@mess-maker I sure didn't! Thanks for bringing it to my attention, I'll have to try it!
Don't forget, that pip and PyPI are not for CPython only -- see https://www.python.org/dev/peps/pep-0425/#python-tag.
I've successfully experimented with different implementation tags and I recommend to consider same route for publishing CP libraries: https://github.com/aivarannamaa/packaging_experiment
I can imagine CP libraries publishing one wheel with CP7 compatible mpy-s, another for CP6, yet another with py-s for MicroPython etc. The CP wheels wouldn't specify Blinka dependency, the MicroPython one would.
If you repeated my experiment with at least one of your CP libraries, then I would make my new project minipip support it (aivarannamaa/minipip#5, please see other issues as well) and we could try to make CP/MP package management less hacky together.
@makermelissa, we started related discussion under Thonny's issues. I hope you're interested in this discussion as well.
@kattni With the addition of all libraries to PyPI for Mu, is this closed, since the answer is now pip?
Sure, I think this can be closed.