A trivial #RakuLang simplification.

I'm never going to remember `zef install --deps-only .` because literally every other package manage has something like `foo install` for installing the dependencies of the current module.

So, i've added this #FishShell abbreviation

abbr -a zdeps "zef install --deps-only ."

maybe i'll remember zdeps

I'd much prefer it if #zef simply said "oh hey, i'm in teh same directory as a META6.json file? I'll install the dependencies" when i run zef install

@masukomi Are you saying when you do

zef install .

it doesn't make sure the dependencies are installed first? That sounds like a zef bug -- what would be the point of NOT installing them?

@colomon

that's a different use case, but yes that does work.

I want to install the dependencies, but not the package itself. Thus enabling me to hack on it.

Like when you run "bundle install" in Ruby or "npm install" in JS

@masukomi So what you're saying is you want

zef install

to automatically do

zef install --deps-only .

?

WDYT @lizmat ?

@colomon @masukomi

If you're hacking on it, how do you run your hacked module? With

-I.

I would hope. In which case it doesn't matter if the module is installed or not.

I find that it actually makes it easier to compare between the installed version and the version you're hacking on: just lose the -I.

Having said that: I wouldn't mind a

zef install

just installing the deps. Once the deps are installed, it wouldn't do them again anyway.

@lizmat

I find that a lot of the time I'm actually making changes to a module alongside changes to another one (or just fixing a bug that afflicts the other one,) so I'm going to do a `zef install` then go to the other module to test (of course one could specify `-I/path/to/changed/module` but that's a lot of typing.)

That is a more frequent operation than installing the dependencies (which only happens once,) for me.

@jns Yeah, I find myself in that situation a lot with the "rak" plumbing and the App::Rak porcelain module. But I don't mind doing the additional " ." in the "zef install --force" on the "rak" module to see its effects on "App::Rak" πŸ˜ƒ

@jns @lizmat

re Liz's "how do you run your hacked module?"

yup, with `-I`

thus my want for `zef install` that just does deps

re Jonathan's "so i 'm going to do a `zef install`

yeah, that's a frequent pattern for me to, but i don't like it.

I'd MUCH rather be able to specify the path to the local lib like other package managers do so that i don't have this annoying uninstall + reinstall cycle which has the "bonus feature" of chewing through thousands of the limited writes on our SSDs

@colomon @lizmat

yup. precisely that.

πŸ€” thinking out loud... maybe `zef install .` should become `zef install this`. (Keep the . for historical support BUT...)

1. I 100% mistook the dot for the end of a sentence first time i read instruction to use it
2. it's easy to miss visually, especially for low vision users
3. IF we made `zef install` (no dot) install deps then `zef install .` feels a little "too close" semantically.
4. "install this" is VERY self-evident. `install .` is VERY geek

@masukomi @lizmat In

zef install .

the period is the path to be installed. I'd be strongly against changing that.

@colomon @lizmat right i get that, and like i said, should be kept for historical support reasons. I was suggesting adding `zef install this` (or something like it).

πŸ€” i wonder how often anyone gives it a path other than `.`

@masukomi @colomon Thinking about this some more, maybe installing the dependencies should have its own main command:

zef deps .

would install all deps of the dist in the current dir. Whereas:

zef deps Foo::Bar

would install all dependencies of Foo::Bar

@lizmat @colomon

πŸ€” thoughts:
"zef deps" i like, but eschews the "install" naming convention of ruby, npm, crystal, and python (although python has extra flags). So, extant knowledge doesn't transfer. I DO, however, like the idea of splitting installation of module vs just its deps. It's more intention revealing.

"zef deps ." I don't like it as required. period's too easy to miss in docs. the need to specify dir for deps only feels _very_ edge-casey to me, but maybe just my inexperience.

@masukomi @colomon I guess we first need to convince Nick Logan for the need of a separate "deps" sub-command.

If that comes to fruition, then we can start discussing whether the absence of a target means current directory.

@masukomi @lizmat For me, this is you talking yourself out of the first change you'd like. If "zef install ." is too close to "zef install", then that's a good argument NOT to have "zef install" rather than discourage people from using a period to mean the current directory, which is standard on every major operating system today.

@colomon @lizmat

period for current dir is standard in operating systems but very NON-standard for indicating the desire to install dependencies in a package manager.

specifying ANY directory when installing deps is non-standard for package managers.

@masukomi

So what about the equally common case where you actually want to install the whole module?

@jns

> what about the equally common case where you actually want to install the whole module?

I'm fine with `zef install .` for installing current dir as module.

HOWEVER there's a valid implication of "these feel too similar"

I still think `zef install` installing deps when sitting next to a META6.json is a good call.

If for no other reason than it lowers the barrier of entry to folks coming from other languages because it's how their PMs work too.

@masukomi I also wish zef install defaulted to NOT running the tests. This being $current-year, I hope most people are using GitHub Actions or some other CI to test their packages before releasing them.

@julia

I'm going to _hard_ disagree with that one Julia ;)

Most devs don't bother with tests. Setting up a CI is even more work.

PLUS different CPU architectures, different OSs, eventually different Raku implementetations?!

No way an average dev can be expected to compensate for all that.

DEFINETLY want tests run on my machine before install.

Otherwise i'm just assuming their πŸ’©works and spend hours banging my head against a wall thinking I screwed up, but it's a lib's bug.