jdsalaro

> This does seem to suggest that there is a very real possibility that they could refuse.

Not at all, on a societal level the US has been increasingly constructed as a huge, intricate, Prisoner's Dilemma where everyone, allegedly, has all to lose and noone, allegedly, has a say in the matter, therefore everyone complies with whatever the system, or media, asks of them.

Everyone thinks they're the victim, everyone thinks civic duty is something the oppressor is responsible for, not them personally, therefore everyone is free to be an oppressor themselves.

This problem will be intensified whenever, as we've seen elsewhere, the military starts being transformed from within and sycophants are put in positions of power.

> With that power, everything is legal.

Although I agree, here I disagree.

In general, the Executive branch, the Intelligence Community, Congress, the Courts, the Populace are all responsible for keeping the President's Office accountable, both officially and extra-officially. Officially, via legal and direct means. Extra-officially, by means of protest, mounting cultural as well as mediatic pressure, etc.

In our, as Trump's actions have greatly affected the international community as well, situation what's most concerning is the initial, slow but eventually complete and absolute breakdown of public discourse.

Truth is irrelevant, poise is impractical, facts are an obstacle, outrage and drama are the new assertive communication. It's all about Me and My Emotions, us versus them.

This has been the case increasingly, for years, on both sides of the political aisle. Everyone compartmentalizes everyone into the sub-groups they are a part of, until everyone is so compartmentalized that they are completely alone because there are no similarities left for any common ground whatsoever. Such is the dystopic portrait of a society in complete disarray.

Under those circumstances, everything is legal, simply because there's noone to enforce the commonly agreed upon Rule of Law.

Are all of your recipes home brewed?

> management is very creative

What you described, I wouldn't accept generally under my definition of creativity.

In order for creativity to be such it must ultimately deliver value; managers "doing their job" in ways which hinder instead of supporting engineers is not creative, it's disruptive.

> The problem is that some methodologies (Scrum, etc.) are heavily abused and transformed into management frameworks, which is the opposite of why they were created in the first place.

At the hands of an uncreative person any tool will be the wrong tool. This is what people fail time and time again to understand.

Any quality work, gain in efficiencies, improvement potential, etc will be hindered by the desire to apply blindly and without creativity any given thought framework.

> He trained for hundreds of hours to fly the capsule manually and the docking process is excruciatingly slow

_COME ON TARS!_

> So that in any directory you can type `<command name>`?

Any tool installed via asdf is available on any directory as long as you are accessing that directory via a shell spawned with a .profilerc or similar which contains your asdf configuration.

> asdf Node installs aren't like Python virtual environments

Correct, neither should they be.

> they're centrally installed and one Node version (and its packages) is shared across all diretories

sure, they are, and that's by design. You're conflating a runtime manager with a package manager. Venvs are _not_ runtime manager, the moment you need another Python version you're done for. asdf.vm is _not_ a package manager, the moment you want package isolation while working on an asdf install is the moment you install yourself pipenv, poetry, pdm or use python venvs for that.

> that want it + global tools.

which is achieved as I've shown below. Still, there was no reason in your usecase to modify or play with globally installed tools besides asdf, through which you can then define global runtime versions and those global versions will hold your global tools, usable wherever.

> pyenv + pip tools

then you'd also need rbenv, nvm, etc.

and pyenv can implode in marvelous ways.

> Why would I want/need this?

always, golang is overly opinionated regarding where modules and binaries are stored. I don't like that and I've blown my local development environment into pieces because of that (looking at you GRPC, yikes)

But also, imagine that you, like me, need to test Python, Java+Kotlin+Gradle and NodeJS+Angular stuff. Do you really want to install _all that_ natively ? Just for a couple of merge reviews, and even if not, do you _really_ want to install all that natively ? The answer is always, IMHO, a resounding and clear no.

> It was a Visual Basic 6 program, so I just took two half days going through every EXE & DLL related to Windows and VB, eventually finding the difference. Tedious but not rocket science. Is it to avoid these cases?

For example, but also much worst, as mentioned in the OP it's to prevent the very real possibility of crippling your OS's language runtimes and also to stay productive.

there's something I don't get, why do you have globally installed tools that asdf can manage at the same time that you have asdf installed?

OP here, although I hoped I took an example that was relatable, it seems it wasn't as relatable as I expected.

> Is it just me that never even wants to get to the problems that asdf attempts to solve?

You aren't alone, the scenario isn't ideal. However, brew's Python installation on MacOS as are Debian's and Ubuntu's are _extremely_ brittle. You are one cask, formulae or apt package away from needing to do a weekend-long spelunking session or a full blown system re-install if you have deadlines.

PyEnv is a pain to set up, and maintain, which is what I used in the years before as well as after Python 2 was deprecated and projects started slowly migrating to newer python versions.

> That example in the article of managing multiple python 2.7 versions sounds like a horror story.

It is a horror story, but is very common.

Have you tried to install and maintain Java, Kotlin and Graddle installations for a given project although your machine is not primarily a Java, Kotlin, Graddle box? That is a real nightmare, not so much with asdf.vm.

My experience with Poetry has been mixed the last couple of times I've tried it, it attempts to do way to many things but often failed to do them properly. Determining dependencies and proper packaging and upload to PyPI are the ones which come to mind.

asdf.vm together with pipenv is my go-to for Python environment management.

this makes me itchy, pulling the whole internet without looking into your development machine sounds like a very bad idea. It's the equivalent of an IDE's "do you trust this project" but on steroids.

> A dockerfile solves that, my system is a carbon copy of the prod environment.

Yeah, that can definitely not be beat, if at all probably only due to comfort.

> Not tried pipenv

I've been meaning to put a tutorial out there with my workflow since forever, if I had it I'd point you to it.

I recommend you give it a try if you get the chance, you might like it.