-
Notifications
You must be signed in to change notification settings - Fork 5
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
apt can (and should?) track other packages #178
Comments
IMO, we should create a virtual environment during installation so that we don't have to care about what's installed on the host (except for C headers and such). |
I see two uses of UltraTrace: development / bleeding-edge and end-user. End-user versions (i.e., obtaining binaries from the releases section) shouldn't need to worry about any of this, but anyone who's doing development or wants the bleeding-edge (i.e., obtaining the source from git) should be able to use whatever comes with their package manager. Being able to create a virtual environment is a good option if a developer wants, but it's a lot of extra work (not to mention resource use) and imho shouldn't be the default. |
Hm, what do you mean by this? I just opened #181, which adds a tool to manage a virtual environment (if you want to use it), and it's pretty straightforward. You just need to type $ source dev/env.sh in a It's true that the virtual environment is a bit chunky (~300 MB on my machine), but I would prefer to optimize for ease of development/distribution over disk usage.
If people want to use their package manager's versions, they can still do that. The install command would look something like $ git clone ...
$ cd UltraTrace/
$ pip install . If we published to PyPI, the above command would be equivalent to $ pip install UltraTrace I'm curious about your "end-user" thoughts here -- I've been assuming that anyone who wants to use this app would install it from source. What kind of "binaries" did you have in mind? |
In fact, using my system-wide
😁 |
I would like to be able to distribute it as something that people can run without needing to figure out Python stuff. I've spent hours helping people try to install it on Windows and macOS, and it's a pain on both platforms (usually requires compiling some non-python libraries from source), mostly because of python libraries that have platform-specific binaries that turn out to be broken/bitrotten on various platforms. Some people just want to annotate ultrasound data... |
This is in fact the reason tracking dependencies in apt is good. We don't care what version of e.g. libmagic someone has, but we do need their python libmagic version to match their system's version, and this is what package managers are for. Virtual environments will result in mismatching versions, which will mean this won't work. |
That's fair, tho it does basically mean that we need to (1) limit ourselves to some lowest-common-denominator feature set, since we don't control when upgrades happen, and (2) ask people to install some Python packages "globally" (either with Alternatively, how would you feel about just distributing a Docker image? I've never used Docker to run a GUI before, but I imagine we just need to set up some kind of forwarding (of X or whatever).. The benefit is that instead of installing any dependencies, users could just
There are a few other small complications I can foresee (needing to mount volumes into the container, needing to host the containers somewhere), but might be worth pursuing? 🤔 |
Ugh, this is why people distribute executables. Docker images are so bloated and require admin access. Not a practical way to distribute stuff. I think in general just having clear information/instructions about dependencies and providing executables for people on Windows is plenty. (But we do need to not have terrible dependencies, e.g. #179). |
Like pyaudio and ttkthemes and pil.imagetk and matplotlib and pydub
The text was updated successfully, but these errors were encountered: