You don’t need Docker, you just need a virtual env for each random thing you try instead of making them all conflict with each other. Maybe some day pip will add a switch to automatically create one, but until then,
python3 -m venv venv
. venv/bin/activate
before you try something random.
Also, `python` is usually Python 2.7. If it is, I advise removing it from your system unless you have a strong reason to keep it.
Nope, this is EXACTLY why I'd use docker. You want to faff around with some esoteric settings? Go for it! But don't make your would-be users runt the gauntlet, that's pointless.
Now your user need to learn a lot about Docker to edit anything. And you need to find a place to host those huge images. What's free today may not be in a year, see Docker Hub.
Edit: Not saying offering it as an option is bad. But your pip install should work regardless, scipy=0.10.1 is bad whether you offer a Docker image or not.
If you don't want to host Docker images, you can just provide a Dockerfile. That way the onus of resolving all the complications is on you - your user only needs to have Docker running on their system.
Arguably, it's a pretty reasonable requirement. Widely used, mature, easy to set up.
I don't remember when I switched to running all my dev envs in Docker, but I wouldn't go back.
How far are we going to need to go to fully abstract these systems? Am I going to need a separate computer running a VM with a server image for hosting a docker image of python venv to manage a package that prints some text?
docker is not the right tool for the job here. this is not an app. this is a nacent project and if you want people to benefit from the underlying code, and contribute back to it to grow this field, you provide proof of concept code, not full, complex and opinionated interfaces that are all crufted up with containerization/packaging. venv is a core module of python and its dead simple to get a virtual environment up and running. you dont have to do any crazy things to expose hardware to it (GPUS), you just run two commands to create and source the environment and then everything just works.
From a linux perspective, I wouldn't blindly suggest the average reader to purge Python 2.7 from their system, as it might drag core parts of the WM with it. Consider aliasing, or better yet, relying on modern venv tools such as Conda instead.
I finally purged python2.7 from all the systems I admin during the Ubuntu 22.04 upgrade cycle. Worked just fine. No reason to keep it around if nothing depends on it, and indeed nothing does. If something does depend on it, think long and hard whether you really need that thing.
× python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [8 lines of output]
Traceback (most recent call last):
File "<string>", line 2, in <module>
File "<pip-setuptools-caller>", line 34, in <module>
File "/tmp/pip-install-i7ubxxkc/scipy_4d5af4f3e2094adca3313ccb41a6d5ff/setup.py", line 196, in <module>
setup_package()
File "/tmp/pip-install-i7ubxxkc/scipy_4d5af4f3e2094adca3313ccb41a6d5ff/setup.py", line 147, in setup_package
from numpy.distutils.core import setup
ModuleNotFoundError: No module named 'numpy'
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed
× Encountered error while generating package metadata.
╰─> See above for output.
note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
[notice] A new release of pip available: 22.3.1 -> 23.1.2
[notice] To update, run: pip install --upgrade pip
(venv) (base) vid@kk:~/D/ai/tortoise-tts$
I'm sure you could eventually help get this working, which is kind of you, but the point is the "supposed tos" don't work either. It needs to be comprehensively fixed if python really wants to be approachable. Maybe it doesn't. It's also just not a good citizen when it comes to heterogeneous apps on the same system.
This isn't the first time venv didn't work for me, then there's anaconda, miniconda, and a bunch of other things that add env and directories. I don't really know what any of them do, and -I don't want to- I'm not an expert on every app on my system, but I can use nearly all of them without pain. (remember this is about ease of use)
Oh yeah, and python 2 vs python 3. <rolls eyes>
It's very much the "works for me" experience from the old days. There's no good learning from it, except dependencies suck and python systems aren't good at them.
I think when releasing anything that includes dependencies that span the operating system, it's just good engineering to use a container approach. Otherwise you're just causing a lot of discomfort in the world for no good reason.
It's funny because chatgpt would give me an answer to this in a few moments, but I'm locked out for a week because it can't figure out where I am.
Now I'm spending my Sunday morning setting up a dockerfile for tortoise-tts. At least I will learn something reusable from that. I guess I will create a PR for it, though it seems the author isn't tending the repo anymore.
Oh I don't disagree, the ecosystem does has a packaging reproducibility and multitenancy problem with out-of-box tooling, and projects seldom provide basic instructions for people outside the ecosystem, like using a virtual env.
That said, this tortoise-tts project might be a particularly bad example. It somehow locks to scipy 0.10.1 from 2012 [1] (during the Python 3.2 release cycle, when Python 3 was heavily in flux) in requirements.txt [2]. Probably not terribly surprising it doesn't work. I didn't bother to look into why they lock to that.
I think I personally keep running into these bad examples every time I use something with Python and I do use venv every time. Rarely something works out of the box. Even colabs I try somehow won't work after a while. There is always some sort of version mismatch, sometimes something like numpy, tensorflow and some other deps.
`rotary_embedding_torch` has not defined any build requirements hence your error: https://github.com/lucidrains/rotary-embedding-torch. You therefore need to install `numpy` before installing `rotary_embedding_torch`.
This is bad, `rotary_embedding_torch` as a package is not in a high enough quality to put as a requirement.
The good news is Pip 23.1+ is forcing the issue, `rotary_embedding_torch` will fail even if you have `numpy` installed because builds by default take place in an isolated environment and you *must* define any build requirements you have. This should force the quality of packages in the Python ecosystem to improve and no longer have this error.
FYI Tortoise, the thing you are trying to build, is abandonware. The creator decided to stop working on it due to “ethics” (i.e only Big Tech should have access to AI) when the community reverse engineered a way to finetune it using weights accidentally left on hugging face. There’s a nice fork out there called mrq/ai-voice-cloning.
It’s been a long time since “Python —version” output “2.x” on a computer I was using. Even macOS is on Python 3 these days iirc. Every Linux distro I’ve installed in the last few months was at least 3.8.
Also, `python` is usually Python 2.7. If it is, I advise removing it from your system unless you have a strong reason to keep it.