[davidy123]

Granted I'm not coming from the python world, but I have tried many of these projects, and very few of them install out of the box. They usually end with some incompatibility, and files scattered all over the place, leading to future nightmares.

  ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
  sentry-sdk 1.22.2 requires urllib3<2.0.0, but you have urllib3 2.0.2 which is incompatible

Just for fun, here's the result of python -m pip install -r ./requirements.txt for tortoise-tts;

…many many lines

          raise ValueError("%r is not a directory" % (package_path,))
      ValueError: 'build/py3k/scipy' is not a directory
      Converting to Python3 via 2to3...

…

  /tmp/pip-install-hkb_4lh7/scipy_088b20410aca4f0cbcddeac86ac7b7b1/build/py3k/scipy/signal/fir_filter_design.py
      [end of output]

  note: This error originates from a subprocess, and is 
  likely not a problem with pip.
  error: metadata-generation-failed

I'm not asking for support, just saying if people really want to make something 'easy' they'd use docker. I gather there are better python package managers, but I gather that's a bit of a mess too.

Someone is thinking "this is part of learning the language," but I think it's just bad design.

[oefrha]

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.

[btbuildem]

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.

All that nonsense vs docker pull / docker run

[oefrha]

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.

[btbuildem]

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.

[GloriousKoji]

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?

[tdhz77]

Yes, if you believe in modern software.

[lambda_matt]

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.

[Nephx]

Dangerous comment.

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.

[oefrha]

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.

I don’t know about desktop Linux though.

[davidy123]

Sorry, but

  (base) vid@kk:~/D/ai/tortoise-tts$ python3 -m venv venv
  (base) vid@kk:~/D/ai/tortoise-tts$ . venv/bin/activate
  (venv) (base) vid@kk:~/D/ai/tortoise-tts$ python -m pip install -r ./requirements.txt
  Collecting tqdm
    Using cached tqdm-4.65.0-py3-none-any.whl (77 kB)
  Collecting rotary_embedding_torch
    Using cached rotary_embedding_torch-0.2.3-py3-none-any.whl (4.5 kB)

…

    × 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.

[oefrha]

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.

[1] https://pypi.org/project/scipy/0.10.1/

[2] https://github.com/neonbjb/tortoise-tts/blob/0ea829d37aa6528...

[pmarreck]

> the ecosystem does has a packaging reproducibility and multitenancy problem with out-of-box tooling

this is exactly why I am learning Nix, to help contain chaotically-designed dependency garbage like this to 1 project directory

[bspammer]

Yep nix is awesome at this kind of thing. Check out this project which packages a couple of AI projects with nix, both work out of the box for me.

https://nixified.ai/

[pmarreck]

oh absolutely YES.

Ironically, the poo of things like python multitenant dependency management will likely push Nix adoption forward (and unfortunately also Docker)

[mewpmewp2]

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.

[notatallshaw]

`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.

[oceanplexian]

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.

[davidy123]

Thanks, I didn't know that backstory. I will check out that repo.

[pmarreck]

Thank you for expressing in practical terms why many people used to better-managed ecosystems are disgusted by Python

[gymbeaux]

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.

[karlicoss]

Or you can use pipx, it deals with all the virtualenv business behind the scenes

[subsaharancoder]

+1 to using venv

[ShadowBanThis01]

Yep, I just tried to install a Python-based project and there was a conflict between Pyenv's and Homebrew's versions of pip... despite having used Homebrew to install Pyenv. I ended up just getting rid of Pyenv altogether... but now Python may be in some screwed-up state on my system.

It's too bad the ecosystem seems to be so messy, because Python seems like the best language for general utilities.

[tedmiston]

> Yep, I just tried to install a Python-based project and there was a conflict between Pyenv's and Homebrew's versions of pip... despite having used Homebrew to install Pyenv.

The comment does not really make sense. It sounds like pyenv wasn't setup correctly on your system (needs to be added to your bash_profile etc). The typical setup is to put pyenv first in PATH so it takes precedence.

It may be easier to use pipx which will auto manage the virtual envs of end user apps for you.

[replwoacause]

This is exactly why I’ve never wanted to get too involved with Python. The few times I’ve tried to play with it, it always becomes a nightmare of error messages to do with stuff exactly like this and I spent more time farting around trying to figure out what went wrong with it then I do actually doing any development.

[RcouF1uZ4gsC]

llama.cpp has revolutionized running these LLMs because it provides a nice, self-contained minimal dependency way to do this.

Python is very fragile to deploy and run on your own machine.

[tedmiston]

Are you familiar with virtual environments? It's the standard Python technique for isolating dependencies across projects. [Most projects mention this in the setup / quickstart section of their docs.]

You should not be seeing these dependency conflict issues if you install each project in its own virtual environment.

If you just want them to be easily installed you can just use pipx (`pipx install my-package`) which will manage the virtual environment automatically.

Making a full blown Docker image for it is overkill 99% of the time. Virtual environments serve the same purpose while being much faster and lighter weight.

[johnnyjeans]

This is the primary reason I'm averse to languages and ecosystems that rely on package managers. I have never had a good experience where these things aren't just constantly breaking. Stack/cabal, cargo, pip, npm/yarn, gem. Scattering files across my filesystem and having extremely brittle configs that shatter the ecosystem into a billion pieces at seemingly random intervals. A problem exacerbated by these package managers often being more complex than the compiler/interpreter itself. Luarocks is probably the least problematic, and that's mostly because it hosts really simple and self-contained software.

Say what you will about the old school way of manually building and copying shit around, at least when something breaks I don't have to spend a couple hours keelhauling a bloated toolchain in a debugger for mutiny.

[seydor]

This is too much to ask for an OSSLM project , considering that it will be obsolete by something else in 7 days or less.

[anaisbetts]

I would say it's more an artifact of historical tech debt that is hard to change now without breaking everyone. As another commenter pointed out, you want to use a venv - I use pipenv as a tool to automate this but there are others as well (poetry is probably better but pipenv seems to work for me).