I don't want to have to set up miniconda. I don't like Python, I am not part of the Python ecosystem, and I don't want to add a bunch of Python tools to my toolchain just to run a friggin' LLM project.
I'm not a C coder either, but I don't complain about those projects because they're almost always "config; make; make install". I basically want something like that, but for Python. The nerd-tapdancing required here is ridiculous.
But it's annoying how many packages like qiime make it basically a requirement to use Anaconda/miniconda. I really don't want to pollute my computer with multiple installations of even things like R just to run a package.
I'm not a huge fan of conda either but your comment is not very constructive without either providing concrete examples of what you mean, or explaining your 'complete insanity' claim. I don't personally see how helping newcomers easily maintain environments with versioned C libraries in them is vile or insane.
If you're just writing "a=b+c"-level Python scripts, or scrambling together tiny flask/django apps, or whatever else, you probably don't care indeed.
If you're doing/learning any kind of data-science-related stuff, that requires tons of C extensions and libraries. And many 'noobs' learn Python in order to use pandas/numpy/torch/whatever else is hot these days.
I'm a complete outsider to the python ecosystem, from time to time I need to write a script or use a popular python library like pygments and I used to hate having to do anything with python because of how difficult it seemed to install anything (cognitive overload of having 20 different ways to install things...).
Anyway, recently I discovered miniconda and it seems like the best, most unambiguous way to install python. It is small (in rel terms...), it works like a charm on Windows, and I can just do something run a single command like `conda install pygments` and I'm all set!
Just not sure why I would ever need to look into something like poetry, although I heard conda and poetry can complement each other somehow? (as do pip, easy_install or whatever is called and all the others haha :-p).
You might want to look at micromamba as a separate tool that can install python itself, libraries, etc. with zero dependency on a python being installed. It's a very fast tool written in C++ so it's easy to install and use almost anywhere. It uses the conda ecosystem of packages.
For most modern ML projects in python you can just do something like `conda env create -f environment.yaml` then straight to `./main.py`. This handles very complex dependencies in a single command.
The example you gave works because llama.cpp specifically strives to have no dependencies. But this is not an intrinsically useful goal; there's a reason software libraries were invented. I always have fun when I find out that the thing I'm trying to compile needs -std=C++26 and glibc 3.0, and I'm running on a HPC cluster where I can't use a system level package manager, and I don't want to be arsed to dockerize every small thing I want to run.
For scientific and ML uses, conda has basically solved the whole "python packaging is a mess" that people seem to still complain about, at least on the end-user side. Sure, conda is slow as hell but there's a drop in replacement (mamba) that solves that issue.
Yeah, I don't really get why Python developers tolerate this state of being where minor point releases are so commonly incompatible with each other, or having no standard way to manage building against different versions. I also don't get why ML developers continue with Python, considering these issues.
But, that's the point of the Miniconda dependency. By using Conda, the project can be setup locally with the Python version it expects without clobbering your local, system-level install.
It was still a bit of a pain to learn how to use Conda, but it worked out a little better than figuring it out on my own.
Miniconda is a pain as it introduces it's own package build format that (IMHO) just isn't very good. It might have been an improvement on python's binary packages when it was released, but now days the conda package format creates more problems than it solves.
>I think of it like a Python VM that just works where ever I place it.
That's called a virtualenv, which is a feature built into python. Miniconda is a thin wrapper around virtualenv (actual python packages) and the conda package format. If you're using an IDE it probably has virtualenv support baked in.
Personally I prefer to use python-poetry for managing virtual envs, but honestly just using the virtualenv command directly is not hard if you're already using conda from the CLI.
> (I dont know why people need that either, my vague impression is that scence-y types want complete pushbutton installation, typing a command == fail, I guess, I dont know).
Essentially, yes, and justifiably so. Try installing science-y Python packages on Windows written in C. When conda was created in 2012 this meant installing Visual Studio 2005 (for Python 2.7) which was hard to find on Microsoft's own website even back then.
yeah it's sad I guess but half the reason I am recommending this is that it "just works" so much more easily than installing half the Python ecosystem into a conda environment (ironically, just so that Python can then behave as a thin wrapper for calling the underlying native libraries ...)
I personally hate Conda with a firey passion - it does so much weird magic and ends up breaking things in non obvious ways. Python works best when you keep it really simple. Just a python -m venv per project, a requirements.txt, and you will basically never have issues.
I think this is an interesting case where people just want different things, and so the thing that they want is "better".
Some people really just want Python+extras and don't want to worry about getting a fortran compiler. Conda is great for this.
Other people really don't want a big meta-install system that bundles a bunch of dependencies. Maybe they're on Linux, they target a single platform, or they want to use a package not in conda that works with a more recent version of the dependencies that conda bundles.
Yeah, gotta setup miniconda to keep things manageable. Basically a generic virtual env manager that is trivial to use. This way you can ensure each one of these LLM projects that want different versions of different libs will get them without stepping on each other or polluting your system.
I'm not a C coder either, but I don't complain about those projects because they're almost always "config; make; make install". I basically want something like that, but for Python. The nerd-tapdancing required here is ridiculous.
reply