3 ms·
By Ruby, Python and JavaScript hackery I was meaning rvm, venv / pip, and npm. I have the most experience with rvm, and the hackery part comes from the experien
by npteljes 5y ago
By Ruby, Python and JavaScript hackery I was meaning rvm, venv / pip, and npm. I have the most experience with rvm, and the hackery part comes from the experience when I created a web interface that could instruct the server to do ruby tasks. Turned out that rvm (and also bundler) does a bunch of stuff to the environment of the user, that's sometimes inaccessible, even if you invoke a "login shell" programatically. One of these "hacks" is doing a bunch of stuff when the user navigates to a Ruby project directory with cd, which is when rvm creates or uses the existing virtual env for the project - named is a specific way based on the directory name. I solved this of course but the discovery was quite annoying.
Regarding Python, I don't have much experience, other than the general feeling that it's fragile and that specific projects work with specific dependency managegers / virtual environments, and they are not really interchangeable or anything. I either could replicate the env or I couldn't. I definitely don't have much of a Python experience.
Now regarding your Java IDE annoyance, I share the same experience. Also the case with Tomcat. IDEs do so much hackery so that user experience is convenient, that you would be hard pressed to replicate the results, and often need to test both because it just doesn't work the same way, due to the different dependencies used, deployment method etc.
Now that I think about it, every single one of the programming ecosystems I used were quite annoying.
- Tainnor 5y ago> By Ruby, Python and JavaScript hackery I was meaning rvm, venv / pip, and npm. I have the most experience with rvm, and the hackery part comes from the experience when I created a web interface that could instruct the server to do ruby tasks. Turned out that rvm (and also bundler) does a bunch of stuff to the environment of the user, that's sometimes inaccessible, even if you invoke a "login shell" programatically. One of these "hacks" is doing a bunch of stuff when the user navigates to a Ruby project directory with cd, which is when rvm creates or uses the existing virtual env for the project - named is a specific way based on the directory name. I solved this of course but the discovery was quite annoying. Keeping the "right context" when you do things in different directories with the same shell config is, unfortunately, a problem that I don't think is easy to solve. My preferred approach is to use direnv (https://direnv.net/ https://direnv.net/), but that's not perfect either. As for rvm, I think that a lot of people at some point discovered that rvm was maybe doing a bit too much (in particular, it would also manage gem sets, something that seems superfluous with Bundler). I think that's a reason why rbenv and chruby emerged as lighter-weight alternatives which are a bit less magic. I haven't seen many people use rvm anymore in recent years. By contrast, Bundler doesn't really do anything to your shell. > Now that I think about it, every single one of the programming ecosystems I used were quite annoying. That's something I agree with. As a more recent convert to the JVM world (and mostly just for lack of better alternatives), I'm still sometimes annoyed at the IDE-centrism (and UI-centrism, see also sonarqube) in this space. Luckily, things are already better than they were when I learned Java in university and "it runs in my IDE" was the default state of affairs...
- npteljes 5y agoThanks for the suggestions. I'll look into direnv, as I only heard about it, but never really investigated. If people don't use rvm, do you know what they use to install a specific Ruby version? We basically use it so that we can use a Ruby that's not bundled with the distros anymore (large legacy project).
- Tainnor 5y agorbenv (together with ruby-build) would be my recommendation.