Brought back from an old commit

[dstromberg]

Restoring the Makefile, to facilitate installing all of micropython-lib.

[stinos]

This uses max-depth=1, does this still work? In any case imo ths should be replaced by Python code so it runs on Windows as well. And the code should allow selecting which of the subdirectories to install.

In a later installment I guess upip should allow installation from a local respository (and from github as well perhaps) like pip and then this tool here would call into upip to do the installation of each module.

[dstromberg]

I've rewritten it in Python 3.4.

Thanks :)

[jimmo]

Thanks @dstromberg

So I can understand this better, what's the underlying workflow that you're using this for? I'm guessing you have the unix build in your PATH, and you want to be able to use micropython-lib packages from anywhere? i.e. you're using micropython's unix port as a cpython-replacement, and ~/.micropython/lib as your site-packages equivalent? Or something else?

My experience is far more embedded-focused, so this isn't a scenario that comes up very often.

[dstromberg]

On Thu, Jun 10, 2021 at 5:09 PM Jim Mussared @.***> wrote:

Thanks @dstromberg https://github.com/dstromberg

So I can understand this better, what's the underlying workflow that you're using this for? I'm guessing you have the unix build in your PATH, and you want to be able to use micropython-lib packages from anywhere? i.e. you're using micropython's unix port as a cpython-replacement, and ~/.micropython/lib as your site-packages equivalent? Or something else?

My experience is far more embedded-focused, so this isn't a scenario that comes up very often

I like exploring different dialects of Python.

And yes, I want to be able to easily use micropython on a Linux system. Actually, I've been patching my micropython binaries to get their library from, EG, /usr/local/micropython-1.15/lib.

I've been intrigued by the possibility that micropython might thread better than CPython and Pypy, so I've had it in the back of my mind to write a little parallel benchmark or two and graph the performance curves.

Thanks.

-- Dan Stromberg

[stinos]

So I can understand this better, what's the underlying workflow that you're using this for? I'm guessing you have the unix build in your PATH, and you want to be able to use micropython-lib packages from anywhere?

That's what we do as well, roughly: to deploy applications which use select items from the micropyton-lib repository we copy over those directories to a lib directory. Which can then get redistributed as-is to other computers. All of this is simpler and faster than using pip, and works without global internet access as well. But as said, in the end it would probably be better to have upip handle this.

I've been patching my micropython binaries

You can set the MICROPYPATH environment variable for that, equivalen of PYTHONPATH, no need for patching.

[dstromberg]

I'd really rather patch the binary, so anyone on the system can use it conveniently.

[dbrignoli]

The original Makefile, which I use to install micropython-lib, doesn't really use or need any features of make and I agree it would be nice to have something equivalent in Python. However, after reading this conversation and comparing the original shell script from the Makefile and the proposed solution in Python, I wonder if the practical and concise solution could be to have a shell script for bash/posix and one for windows.

[stinos]

Note that if it weren't for the copy-tree implementation combined with using argparse this would be pretty concise.

But the more I think about it, the more I feel the way forward is to use upip. It already knows which files to skip and how to copy the files etc, just needs some extra bits to not unpack a tar from a URL but to use files on disk. Then unless I'm missing something the installation here would be just 'for subdir in listdir(mainDirs): upip(subdir)'. But changing upip might be non-trivial, don't know.