4 ms·
> argh & a symlink in /usr/bin. - Is putting a symlink to one of your project directories, probably residing in $HOME, to /usr/bin/ a good practice? - As an a
by yeti-sh 3y ago
> argh & a symlink in /usr/bin.
- Is putting a symlink to one of your project directories, probably residing in $HOME, to /usr/bin/ a good practice?
- As an alternative one can put a symlink into ~/bin; but what if you have multiple different projects?
- And they can have different jeeves commands and different plugins installed. For instance, `j lint` implementations in different projects are work on are completely different.
Because these are different projects.
Rather, I prefer to have jeeves automatically create the executable command in each virtual env, and its behavior in different virtual envs will be different.
- culebron21 3y agoI mean `sudo symlink /usr/bin/python3 /usr/bin/p` can make a good shortcut for python. The script name can be tab-completed.
- yeti-sh 3y agoI see. The P key isn't that ergonomically placed though; and again, one will have to do this time and again for each virtual environment, right? Why not use native Python methods, namely endpoints, instead, and automate this away?
- culebron21 3y agoOn Dvorak keyboard it is in a very convenient place. Anyway, one can assign any letter. Not everyone uses virtualenv -- this is very frequent in Django, but I didn't see it elsewhere since I stopped working with it in 2016. Data science that I saw, revolves around Jupyter and Docker. Anyway, my point is that your package offers conveniences like those in existing packages, and not free but at a similar cost. (Actually, I also contemplated making my own plugins system for `argh`, but just wrote a single package with my own decorator to handle just the few types I needed: pd.DataFrame and gpd.GeoDataFrame. https://github.com/culebron/erde/ https://github.com/culebron/erde/ )
- yeti-sh 3y agoI feel the majority still uses qwerty keyboards; I assumed that when choosing the name and the shortcut for the tool. Experiences differ, and de gustibus on est disputandum; in my bubble, virtualenv is a must-have for Python development. I have multiple Python projects, they run different versions of Python itself and its libraries, and for many of them Docker would be an overkill; so it is hard for me to imagine my routine without virtual environments. I employ pyenv to manage them but venv is a venv.