search

SwatPhonLab / UltraTrace

A Free/Open-Source tool for manual annotation of Ultrasound Tongue Imaging data.
GNU General Public License v3.0
10 stars 5 forks source link

Manage non-standard libraries #88

Closed keggsmurph21 closed 4 years ago

keggsmurph21 commented 4 years ago

It might be nice to keep a copy of all of the external libraries we depend on somewhere (e.g. under /lib) so that we don't have to rely on the user installing with pip or conda or whatever.

jonorthwash commented 4 years ago

Actually, what I meant wasn't putting external libraries into a folder—I'm happy with users using pip, etc.

What I had in mind was putting things like the new logging library and anything else we separate out from the main UltraTrace.py file into a subdirectory (as opposed to leaving them in the root directory) in order to keep the main directory of the repo clean.

kmurphy4 commented 4 years ago

Ah, that makes sense. I've actually been implementing something along these lines -- I pushed ~25 commits today that restructure the code formerly in in UltraTrace.py (without really rewriting any of it).

Have you checked that out?

jonorthwash commented 4 years ago

Oh my. Yes, that's what I had in mind, I guess. I wasn't imagining separating everything out [yet], but okay.

So... how is UltraTrace run now?

kmurphy4 commented 4 years ago

Just python3 -m ultratrace /path/to/data (-m is for "module").

jonorthwash commented 4 years ago

Just python3 -m ultratrace /path/to/data (-m is for "module").

From within the main code directory or from within the directory containing the code's root directory?

jonorthwash commented 4 years ago

Also, this is a little less than ideal. Before we could just execute the UltraTrace.py script, either from within the directory or from elsewhere, e.g.

$ /path/to/UltraTrace/UltraTrace.py /path/to/data

Is there a way we could make it this easy again?

kmurphy4 commented 4 years ago

From within the repo's main directory:

$ git clone [...]/ultratrace
$ cd ultratrace
$ python3 -m ultratrace /path/to/data

I'll add a little executable wrapper tomorrow that will restore this functionality to something like:

$ /path/to/ultratrace /path/to/data

Sorry for the confusion, but I think using Python native modules is the best way to go, even if it makes calling a bit awkward (since this allows us to have hierarchical imports & such).

On Mon, Dec 2, 2019, 10:23 PM Jonathan Washington notifications@github.com wrote:

Also, this is a little less than ideal. Before we could just execute the UltraTrace.py script, either from within the directory or from elsewhere, e.g.

$ /path/to/UltraTrace/UltraTrace.py /path/to/data

Is there a way we could make it this easy again?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SwatPhonLab/UltraTrace/issues/88?email_source=notifications&email_token=AM2WLGXQ5T2WD2V3ODKYW7DQWX3OTA5CNFSM4JUP7CLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFYH4CA#issuecomment-561020424, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM2WLGVZIPWCOKHKFMQBMBDQWX3OTANCNFSM4JUP7CLA .

kmurphy4 commented 4 years ago

Regarding portability of the executable wrapper, can I assume that this will only be run on MacOS & Linux? I don't have a Windows environment to test with.

On Mon, Dec 2, 2019, 10:38 PM Kevin Murphy kevin.murphy@everlaw.com wrote:

From within the repo's main directory:

$ git clone [...]/ultratrace
$ cd ultratrace
$ python3 -m ultratrace /path/to/data

I'll add a little executable wrapper tomorrow that will restore this functionality to something like:

$ /path/to/ultratrace /path/to/data

Sorry for the confusion, but I think using Python native modules is the best way to go, even if it makes calling a bit awkward (since this allows us to have hierarchical imports & such).

On Mon, Dec 2, 2019, 10:23 PM Jonathan Washington < notifications@github.com> wrote:

Also, this is a little less than ideal. Before we could just execute the UltraTrace.py script, either from within the directory or from elsewhere, e.g.

$ /path/to/UltraTrace/UltraTrace.py /path/to/data

Is there a way we could make it this easy again?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SwatPhonLab/UltraTrace/issues/88?email_source=notifications&email_token=AM2WLGXQ5T2WD2V3ODKYW7DQWX3OTA5CNFSM4JUP7CLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFYH4CA#issuecomment-561020424, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM2WLGVZIPWCOKHKFMQBMBDQWX3OTANCNFSM4JUP7CLA .

keggsmurph21 commented 4 years ago

I added an executable and an installation script here. They work on my Ubuntu system, but I haven't had the chance to test on MacOS (I'm a little worried about the readlink command ... I'm not sure MacOS calls it the same thing).

The executable gives you the same behavior as before:

$ /path/to/ultratrace/bin/ultratrace /path/to/data

And the install script (at the moment) just places a symlink into a prefix of your choosing (by default into /usr/local/bin, which should be on your path). That way you can do things like:

$ sudo /path/to/ultratrace/bin/install # only needs to be run once
$ ultratrace /path/to/data

Is this the functionality you expect?

jonorthwash commented 4 years ago

I think using Python native modules is the best way to go

I agree.

I added an executable and an installation script

Thanks. Yes, this looks like the right approach. I can test on Debian, Mac, and Windows and let you know.

(I don't even know how to run python stuff on Windows, but I guess I'll figure it out. Maybe I'll try WSL?)

In the future, that installation script could (should?) check/install/update external dependencies, with the method for doing so depending on the OS. We could also do some virtualisation or something to test that it all works in a vanilla environment?

One way to do an installation script is as a Makefile, like the following excerpt of what I used for Ling 073 misc tools:

PREFIX ?= ~
install:
    @install -d $(DESTDIR)$(PREFIX)/bin
    install -m755 morph-test.py $(DESTDIR)$(PREFIX)/bin/morph-test
    install -m755 morphTests2yaml.py $(DESTDIR)$(PREFIX)/bin/morphTests2yaml
kmurphy4 commented 4 years ago

I'm only vaguely familiar with make. Is that invoking the install(1) command?

keggsmurph21 commented 4 years ago

Also, if we're going down this rabbit hole, we could set up a travis-ci pipeline for free since we're an open source project.

jonorthwash commented 4 years ago

I'm only vaguely familiar with make. Is that invoking the install(1) command?

With that Makefile, you would just run make install, potentially with sudo, and it would execute the commands in the install block.

jonorthwash commented 4 years ago

Also, if we're going down this rabbit hole, we could set up a travis-ci pipeline for free since we're an open source project.

Yeah, that's the sort of thing I had in mind when I brought up virtualisation. But that's a down-the-road sort of thing. Maybe we could open an issue for it so we don't forget about it, and worry about it later.

keggsmurph21 commented 4 years ago

I'm only vaguely familiar with make. Is that invoking the install(1) command?

With that Makefile, you would just run make install, potentially with sudo, and it would execute the commands in the install block.

Right, I understand that part of it. I was curious about the actual contents of the install block (is "target" the right lingo?) though :)

jonorthwash commented 4 years ago

I'm actually not all that familiar with how install works, but man install gives some info.