[HN Gopher] "You meant to install ripgrep"
___________________________________________________________________
"You meant to install ripgrep"
Author : micouay
Score : 153 points
Date : 2022-10-17 15:53 UTC (7 hours ago)
(HTM) web link (crates.io)
(TXT) w3m dump (crates.io)
| typon wrote:
| Neovim + Telescope + ripgrep. It's taken 30 years, but we finally
| have the perfect code navigation solution.
| aidos wrote:
| Amen to that!
| burntsushi wrote:
| Hah! TIL. I had no idea someone did this. But it's smart. I
| should have thought of it!
|
| (I'm the author of ripgrep.)
| ivanche wrote:
| I love HN because of this :) Thank you so much for making
| ripgrep! You made people's lives easier.
| aryik wrote:
| Unrelated, but thank you for your work!
|
| You've saved me tens if not hundreds of hours with ripgrep, and
| I've become a huge evangelist of it at my workplace. When I'm
| helping someone understand how to debug customer issues, the
| first thing I tell them is to install ripgrep. Truly a
| fantastic piece of software.
| burntsushi wrote:
| w00t! Thanks for the kind words. :-)
| carlhjerpe wrote:
| "gron | rg", because life is too short to learn jq.
|
| Amazing work on rg!
| tambourine_man wrote:
| OMG, thank you. jq is great but its syntax is impossible
| to memorize. This is so much better.
| carlhjerpe wrote:
| Any time! Yeah jq is great, but my usecase is covered
| better by these two together.
|
| Truly the Unix philosophy at it's finest. It's the only
| way I search JSON these days! (or YAML with "yq | gron |
| rg" to get results, pop into (n)vim and to my thing :)
| BossingAround wrote:
| Would you consider taking the "rg" package and redirecting
| people to ripgrep? I mean, asking the current owner to kindly
| donate it to you.
| burntsushi wrote:
| Yes, I'd be fine with that. I just spent a few minutes
| looking for their contact info, but I can't find it.
|
| EDIT: Found their email via git. Always forget about that
| one.
| Jenk wrote:
| There's a pun about finding to be had here.
| darksaints wrote:
| Just want to thank you for ripgrep and your other rust
| contributions. Ripgrep is insanely powerful and is absolutely
| indispensable for me.
| nicce wrote:
| It is smart, in multiple ways. For some guys who don't know
| why, it prevents supply chain attacks.
| wincy wrote:
| I use ripgrep on git bash for Windows, and my team members act
| like I've got searching superpowers. Searching on windows is
| such a pain and this makes it easy. Thanks so much for making
| this fantastic tool!
| burntsushi wrote:
| Hah, w00t. Have your teammates figured out that your
| superpowers are teachable? :-)
| locusofself wrote:
| doesn't vscode use ripgrep under the hood when you search
| your open files/repos?
| burntsushi wrote:
| Yes. But you might not be using VS Code. :-)
| stjohnswarts wrote:
| I use ripgrep and "everything" all the time on windows to
| find files and where I put stuff :) . My filing system leaves
| something to be desired, as does my many idea test folders.
| skunkworker wrote:
| `ripgrep` is my favorite of the "new" linux utilities, it makes
| searching for a single string across all of my cloned repos
| extremely easy, and especially for diving into multiple
| versions of vendored dependencies.
| salawat wrote:
| You should _not_ have done this unless you want to further
| normalize the practice of namespace squatting. This is the same
| type of behavior leads to domain squatting. While arguably
| being slightly more benign in the sense of hedging against
| typosquatting, if everyone started going things like that, we
| 'd quickly begin to run into namespace exhaustion problems as
| people started ballooning their package namespace footprint.
|
| Before you do something like that, always ask yourself: "What
| if everyone else started doing this?"
|
| If the result feels like a nightmare in the making, don't do
| it.
| burntsushi wrote:
| > Before you do something like that, always ask yourself:
| "What if everyone else started doing this?"
|
| No, I don't think so. There is no universality implied in my
| comment or in the specific practice here. You can make value
| judgments based on specific circumstances. For example:
|
| * How many people try 'cargo install rg' and have it do the
| wrong thing? I'd say "probably a lot."
|
| * Is 'rg' on its own something that is a likely useful or
| desirable name on its own? No, I don't think so.
|
| This doesn't have to mean that everyone should do it for
| every possible alias of every crate out there. You can say
| things like "yeah I think it makes sense to squat a name here
| to improve failure modes for folks."
|
| Other than that, I have squatted a few names before. I don't
| see anything wrong with the practice in and of itself. It's
| when it gets abused that it starts to become a problem.
| woodruffw wrote:
| I've worked on various package management ecosystems for
| close to a decade now, and I wouldn't qualify this (if
| 'burntsushi had done it) as namespace squatting. It's clearly
| not an attempt to reserve a name for unspecified future use
| (or as a potential typosquatting target); it's the name of
| the binary installed by the crate and an _obvious_ mistake
| for an installing user to make.
|
| Even flat namespaces are virtually infinite; a couple of
| extra names that correct user error do not pose a serious
| exhaustion risk.
| 0xbadcafebee wrote:
| I'm fully in support of exhausting namespaces in programming
| languages. It's really annoying that people keep making one-
| off projects with weird names that reinvent the wheel.
|
| In CPAN, you create a module with a hierarchical name
| (Net::LDAP), and people inherit from it and extend the
| namespace to add new functionality (Net::LDAP::Batch).
| Finding a package that does what you want is [relatively]
| easy. Old code gets maintained rather than somebody
| reinventing it for the 72nd time with a hodge-podge of
| functionality.
| maxbond wrote:
| I'd like to note there are three perverse incentives that
| lead to abuses of public namespaces (that I am aware of -
| please tell me if I've missed any):
|
| 1.) The use of names as a speculative financial instrument
| (in all shades of grey, up to and including extortion for
| lapsed or stolen names)
|
| 2.) The use of names as vectors of attack, such as by
| exploiting typos or homographs (such as malicious packages)
|
| 3.) The reserving of names you don't have a sincere or
| immediate intention to use (hoarding/FOMO)
|
| This isn't very much like the situation with domains, which
| is primarily a result of #1 (there is no market for crates.io
| names, as far as I'm aware). #3 is a problem to some degree
| on crates.io, my understanding is that they basically treat
| this as a human moderation problem. #2 is endemic to all
| package managers.
|
| By putting a helpful instead of malicious package here, the
| community (and Richard Dodd in particular) are able to
| mitigate the hazard of #2 (unless this account is compromised
| or turns malicious - a better but imperfect situation). If a
| project called `rg` comes around, they can appeal to
| moderators to get this name, and probably succeed (as if this
| were a #3 problem).
|
| This isn't a perfect way to do things by any means, but it
| seems like a decent balance of concerns to me.
| trashburger wrote:
| >#2 is endemic to all package managers.
|
| It is endemic to package managers which don't do curation,
| which is why I'm a fan of package managers that do.
| maxbond wrote:
| Sure. Really I meant "language community package
| registries," which are necessarily open bazaars from
| which more selective repositories can be drawn.
| Macha wrote:
| > #3 is a problem to some degree on crates.io, my
| understanding is that they basically treat this as a human
| moderation problem
|
| I think it's more accurate to say that they consider
| dealing with this out of scope. "I want this name that has
| been unused since it was added as a placeholder package 7
| years ago" is not something that the human moderation will
| help you with. The extent of human moderation on crates.io
| is basically "This is malicious or illegal and was reported
| to us and we looked and agreed so removed it"
| maxbond wrote:
| Gotcha, that was a misunderstanding on my part. Thanks.
| meowface wrote:
| I think this is akin to saying nytimes.com buying nyt.com and
| redirecting it to nytimes.com is domain squatting.
| OJFord wrote:
| Someone else already has 'nyt.com' ('rg'), GP is saying
| (not saying I agree) 'nytimes.com' ('ripgrep') behaviour
| encourages other someone elses to do that sort of
| squatting, where they _don 't_ own the thing that is
| clearly intended.
| Dylan16807 wrote:
| > Before you do something like that, always ask yourself:
| "What if everyone else started doing this?"
|
| Seems fine to me. Something like one tenth of packages
| reserving a second name? Not a big deal.
| c7DJTLrn wrote:
| Crates should be namespaced by user. This is a disaster waiting
| to happen.
| stjohnswarts wrote:
| I don't think so. ripgrep could easily become super cluttered
| if any john-joe-jimmy-larry could namespace it
| PartiallyTyped wrote:
| I agree, same for PyPI and all package repositories.
| pornel wrote:
| Then you'd have people installing "burnedsushi/ripgrep" instead
| of "burntsushi/ripgrep". It only kicks the problem one step
| down without fixing it.
| jrochkind1 wrote:
| worse, if the correct one was `burntsushi/ripgrep`, someone
| else would just squat `ripgrep/ripgrep`.
| remram wrote:
| Do you change the name every time there is a change in the
| maintainers' team?
|
| If you have `ripgrep-team/ripgrep` rather than `ripgrep`, it
| doesn't help at all with people typing the wrong thing, like
| `rg-team/rg`. I fail to see how it helps.
|
| It's even worse with packages that are (currently) authored by
| a single person, how many people know the name of ripgrep's
| author? Or rand? Or bevy?
| seanw444 wrote:
| Is there no way to have a package mirror, or alias or something?
| Unless I'm missing a joke or something, this seems like an easily
| solvable problem.
| VWWHFSfQ wrote:
| I think you would rather have explicitly named dependencies. I
| don't want a bunch of aliased dependencies redirecting to
| wherever
| stjohnswarts wrote:
| I'm the same, I'd rather it be broken so I can figure out
| what's going on rather than bounced around all over the
| place.
| kevincox wrote:
| It is likely better to get the error and fix the mistake than
| be relying on an redirect owned and operated by who-knows-who
| indefinitely.
| woodruffw wrote:
| Aliases turn a flat namespace into a potentially cyclical
| graph, and introduce all kinds of permission considerations
| (Should a non-owner be able to alias a project? If so, should
| they be allowed to update it?).
|
| The solutions here are non-flat namespacing (which has worse
| UX, since `cargo install some-tool` now becomes `cargo install
| whats-their-handle-again/some-tool`) or some kind of content
| addressing (which is similarly bad for UX, if not worse). Most
| package indices choose neither, and "solve" the problem by
| playing whac-a-mole with abuse instead.
| tomjakubowski wrote:
| Clojars has the right idea for namespacing: some-tool is an
| alias for some-tool/some-tool.
|
| This means the first package to squat on the name can use the
| shorthand version, while allowing other packages with the
| same name in other namespaces. (which may be forks or
| entirely different packages)
| benreesman wrote:
| In spite of some tense conversations with the author I am still a
| rg super fan: it's fantastic, reliable, performant, well-
| maintained software and I would recommend it to anyone. It's best
| in class.
| remram wrote:
| Similar in the Python world: https://pypi.org/project/sklearn/
|
| This one just depends on the correct `scikit-learn` package
| though.
| walthamstow wrote:
| Also bs4 / beautifulsoup4
| OJFord wrote:
| These are both like numpy & pandas in always documenting with
| `import longname as ln` right? I think they bring it on
| themselves.
| remram wrote:
| No, it's worse, if you `pip install scikit-learn` you get a
| library importable as `import sklearn`. It's more than a
| usage or documentation issue, the code itself doesn't match
| the name on the can.
|
| (and `pip install beautifulsoup4` lets you `import bs4`)
| learndeeply wrote:
| Same for: https://pypi.org/project/pytorch/
|
| > You tried to install "pytorch". The package named for PyTorch
| is "torch"
| jfk13 wrote:
| Huh - the same author also has https://crates.io/crates/memap and
| memap2, which explicitly say that they're "squatting to prevent a
| malicious typo package".
|
| Not sure how to feel about this... on an individual-package
| level, it seems a sensible enough idea, but if it becomes a
| widespread practice, the namespace could get really cluttered.
| [deleted]
| sedatk wrote:
| I guess "owner/packagename" convention could solve such issues
| as it's common with other package ecosystems.
| Macha wrote:
| Just moves the problem to packagename/packagename looking
| like a more "official" source.
| burntsushi wrote:
| Right. So then you add burnsushi/ripgrep instead. See the
| problem?
|
| Namespaces are a solution or mitigation to some problem, but
| that problem is not malicious typo-squatting.
| stonemetal12 wrote:
| >See the problem?
|
| The only problem I see is that I don't know who owns
| ripgrep, so sticking some random name in front of it only
| adds to my confusion.
| return_to_monke wrote:
| yup! And what if i reserve ripgrep/ripgrep as a
| typosquat, while the real one is burntsushi/ripgrep?
| burntsushi wrote:
| Yes. And the "random name" can be typo-squatted too.
| Compare burnsushi and burntsushi. I myself make that typo
| on occasion. :)
| carlhjerpe wrote:
| Popular crates could be "symlinked" into a global
| verified namespace, problem solved? I can't see any
| downsides other than some extra administration perhaps.
| Macha wrote:
| To me the problem solved by namespaces is making it clear
| what's an official package of a project and what's a non-
| malicious third party package intended to work with that
| project.
|
| e.g. bevy and amethyst have claimed a load of crate names
| like bevy-x or amethyst_y because they thought they might
| release an official addon to their framework to handle
| those areas. e.g. bevy did it with this
| https://github.com/bevyengine/bevy-crate-
| reservations/blob/m... and amethyst did it the long way as
| far as I know
|
| Organisations wanting to have consistent package names and
| users wanting to identify related packages are smaller
| problems than the "all the good names are taken" and
| "packages can impersonate other packages with typos"
| problems.
| burntsushi wrote:
| I'm not sure I necessarily agree with that... But yeah I
| specifically did not want to get into what namespaces
| _do_ solve, and so was instead vague and just
| acknowledged that they 're good for _something_. :-)
|
| I will also say this: at the level of personal
| preference, and given my understanding of many other
| package ecosystems, I would have preferred namespaces
| from the start. But I don't feel very strongly one way or
| the other to be honest.
|
| There is a related RFC open: https://github.com/rust-
| lang/rfcs/pull/3243
|
| > "packages can impersonate other packages with typos"
| problems
|
| I was pointing out that this is specifically not solved
| at all by namespacing. A package's name includes its
| namespace, and the namespace can be typo-squatted. (EDIT:
| Or wait, maybe I'm misunderstanding what you're saying.
| Perhaps I'm confused by what "these" refers to in your
| last sentence.)
| Macha wrote:
| I edited to clarify.
| sedatk wrote:
| For malicious intents, yes. But, for legitimate reasons
| where you need to have an "rg" package with a completely
| different use case, owner namespaced packages might provide
| a uniform solution.
| KMnO4 wrote:
| > but if it becomes a widespread practice, the namespace could
| get really cluttered.
|
| Crates.io is incredibly cluttered with namesquatting. It's
| probably the worst package registry for it, even surpassing
| NPM.
|
| Part of the problem is that they explicitly say name squatting
| isn't against the rules.
| noswi wrote:
| What does one do if they wish to see the actual contents of this
| crate? The web interface I'm looking at contains no hints at
| peeking inside, not even direct archive download links, nothing.
|
| I can't believe that a good way to see what's inside is to make a
| rust project, add the crate and then go searching around the
| local filesystem.
| pie_flavor wrote:
| The source is hosted alongside the documentation at
| https://docs.rs. But far simpler than that is just going to the
| prominent GitHub link.
| maxbond wrote:
| In this case, there isn't a GitHub link, as there's no
| repository in the Cargo.toml:
| https://docs.rs/crate/rg/0.1.0/source/Cargo.toml
| ripley12 wrote:
| crates.io is a little bare-bones sometimes.
|
| I usually use lib.rs instead: https://lib.rs/crates/rg
|
| That has a link to source:
| https://docs.rs/crate/rg/0.1.0/source/
|
| And here's the Rust code:
| https://docs.rs/crate/rg/0.1.0/source/src/main.rs
| samatman wrote:
| If a package manager is starting from zero, and wants to have a
| privileged namespace such that a short name has a canonical
| value, it would make sense for those packages to be able to
| include a list of strings which the package should also reserve.
|
| That way "ripgrep" could include "rg", searching cargo for "rg"
| brings back "ripgrep", not a second package named "rg", and an
| install could tell the user the correct name for any attempt to
| install it.
|
| This also covers typo-squats, so there would be no need for
| packages like "memap".
|
| Obviously this represents a low-effort vector for massive
| squatting, so maintainers would need to be responsible for
| preventing that, and could add some typos themselves, being the
| ones which see the request for the mis-typed packages.
| [deleted]
| secondcoming wrote:
| Is it faster than Silver Searcher (ag)?
| burntsushi wrote:
| Yes. And less buggy.
|
| If someone can find a meaningful case where ag is faster than
| ripgrep, then I'm happy to accept a bug report. I'll do my best
| at that point to give an analysis of the benchmark, and if it's
| correct, I'll either try to fix it or say why it's hard to fix.
|
| By "meaningful" I mean "something that is noticeable to
| humans." So for example, reporting a bug because ripgrep took
| 9ms and ag took 7ms on a tiny repo is one I would consider
| _not_ meaningful. :)
|
| (Sorry about the verbose caveats, but just trying to head off
| responses I've got in the past.)
| woodruffw wrote:
| This classic version of this in the Ruby ecosystem is
| "bundle"[1], which helpfully installs `bundler` for you. Of the
| 6.7 million downloads it has, I'm probably in there a dozen or so
| times.
|
| [1]: https://rubygems.org/gems/bundle
| willlll wrote:
| I appreciate each and every download.
| steveklabnik wrote:
| There's also "nokogirl"
| micouay wrote:
| `rg` has only one version, and one line of code:
| println!("You meant to install ripgrep: type `cargo uninstall rg`
| followed by `cargo install ripgrep`");
| dtolnay wrote:
| Seems like it would be better to contain:
| compile_error!("You meant to ...");
|
| so that the install would fail and `cargo uninstall rg`
| wouldn't be needed.
| burntsushi wrote:
| Yeah that sounds much nicer.
| taink wrote:
| Can always-failing-to-compile crates be deployed to the
| registry?
| Arnavion wrote:
| crates.io doesn't try to build crates. It couldn't do that
| anyway. Crates can require arbitrary C library
| dependencies, only run on some specific targets, etc.
| That's why docs.rs has to make some effort to be able to
| build crates, and even it doesn't get all of them.
| oconnor663 wrote:
| Yes, `cargo publish` has the `--no-verify` flag if you want
| to force this. I think all the verification is client-side.
| orf wrote:
| Yes
| filereaper wrote:
| Can't tell you how often I've run: `pip install aws`
|
| This installs a library by some authors not affiliated with AWS.
|
| Instead of: `pip install awscli`
|
| Which is what you expect.
| mherdeg wrote:
| Wow, it's been years now since I typed "sl" at a terminal and got
| an ascii steam locomotive.
| jimjimjim wrote:
| it's a nice touch that sl includes a man page and command line
| flags
| lifthrasiir wrote:
| It was a helpful reminder to finally learn Ctrl-\ for SIGQUIT.
| rsr wrote:
| A friend of mine in college installed this on my laptop when I
| had my back turned. For a month or so, I wondered why anyone
| thought this feature was a good idea, and why no one I knew who
| used MacOS seemed to complain about it.
| debacle wrote:
| What is ripgrep?
|
| Edit: Because I'm on a Zoom call that will never end.
|
| "ripgrep is a line-oriented search tool that recursively searches
| the current directory for a regex pattern. By default, ripgrep
| will respect gitignore rules and automatically skip hidden
| files/directories and binary files."
|
| https://github.com/BurntSushi/ripgrep
| kibwen wrote:
| A grep alternative that optimizes for performance:
| https://github.com/BurntSushi/ripgrep . There are detailed
| performance comparisons and discussions in the readme there.
| tmtvl wrote:
| A file searcher akin to grep, ack, or ag (aka the silver
| searcher) it's programmed in Rust so it is decently fast with
| good support for UTF-8.
|
| Unfortunately it defaults to parsing a git tree's gitignore
| file and skipping over files listed in it.
| enriquto wrote:
| > it defaults to parsing a git tree's gitignore file and
| skipping over files listed in it
|
| Is that true? How could anybody think that this non-
| orthogonal monstrosity would make any sense?
| burntsushi wrote:
| That monstrosity is easily one of the two most popular
| reasons cited by folks as being the reason why they
| use/like ripgrep. (With the other reason being
| performance.)
|
| Orthogality is a means to an end, not an end itself.
| stjohnswarts wrote:
| because it suits the pragmatic 90% case and not some
| "what if" scenario. It has quite adequately outlined what
| files it does search and also how to overcome the
| defaults. If you use CLI you can use --help as well and
| get the other options.
| nicoburns wrote:
| It's what you usually want when searching code bases. It
| includes all your source code but excludes generated code
| and build artefacts.
| nrabulinski wrote:
| Because you hardly ever want to grep through your build
| artifacts or node modules? I don't remember any one time I
| had to explicitly tell ripgrep to search through all the
| files in a repository
| tmtvl wrote:
| Ah, someone who hasn't experienced the... experience of
| working on a project that does very esoteric autotools
| magic.
|
| I will agree that in a sane project setup you don't need
| to search through all files including build artifacts
| ignored by git.
| cptroot wrote:
| It's the correct default for me. I don't want to grep
| heinous output files by default, like my gigabytes of
| generated KML files. I appreciate that rg (and ag) ignores
| those files by default, and 90% of the people I show it to
| agree.
| burntsushi wrote:
| It also defaults to ignoring hidden and binary files. It's
| also simultaneously the thing folks cite as their favorite
| part about ripgrep.
|
| The idea behind it is that it acts a heuristic for reducing
| false positives from your search results. For example,
| ripgrep replaced several little grep wrapper scripts I had in
| ~/bin.
|
| And _fortunately_ the default behavior is easy to disable.
| `rg -uuu foo` will search the same stuff as `grep -r foo .
| /`, but will do it faster.
| agateau wrote:
| I love that ripgrep honors .gitignore, but the fact that it
| skips hidden files is annoying because of questionable
| decisions from tool makers who insist their configuration
| files should be hidden files. It is especially infuriating
| when working with GitHub and GitLab configuration
| directories. On the other hand I never want ripgrep to
| enter the .git directory.
|
| I recently came up with this alias to make ripgrep do what
| I want: do not skip hidden files, except for the .git
| directory:
|
| alias rg="rg --hidden --glob '!.git/'"
|
| (Note: if you try entering this alias interactively, you
| may have to escape the '!'...)
| burntsushi wrote:
| Yeah that alias is a good one, here are some other
| avenues:
|
| * The repo can add a `.ignore` or a `.rgignore`
| whitelisting things like `.github`. ripgrep will pick up
| that whitelist automatically and search `.github` even
| though it's hidden. But this relies on the repo adding
| ripgrep-specific config files, which is maybe not so
| realistic. (Or not universal enough to rely upon.) But it
| could work fine for repos under your control.
|
| * Add '!.github/' to, e.g., `~/.config/ripgrep/ignore`,
| and then add `alias rg="--ignore-file
| ~/.config/ripgrep/ignore"`. That will become a global
| ignore file (with low precedent) that will whitelist
| `.github` everywhere.
| agateau wrote:
| I use ripgrep everywhere, not only in my own
| repositories, so the first approach won't work for me.
| The second one, on the other hand, sounds like a really
| good idea, going to look into it, thanks.
|
| And of course, thanks for this wonderful tool!
| stjohnswarts wrote:
| just use --hidden, people shouldn't be afraid of typing an
| additional word. I prefer the defaults to keep things clean.
| kevincox wrote:
| "decently fast" is a significant understatement. It is likely
| the fastest similar tool. (`git grep` may win due to not
| listing the directory tree and packed files and GNU grep is
| very fast if you don't use Unicode, but other than that
| ripgrep wins).
| underyx wrote:
| I maintain a Python package that parks names like this. There's a
| Python library called pypi-parker[0] that makes it really easy to
| do this via CI.
|
| [0]: https://pypi.org/project/pypi-parker/
| woodruffw wrote:
| For what it's worth: using a tool like pypi-parker technically
| violates PEP 541[1], since it uploads projects with no
| functionality _solely_ to reserve parts of the namespace. You
| may or may not get away with using it, depending on _how_ you
| use it, but PyPI 's admins (who I do not speak for) would be
| within their enumerated rights to ban any account that uses it
| to squat names.
|
| [1]: https://peps.python.org/pep-0541/#invalid-projects
| underyx wrote:
| Thanks for flagging this, I was unaware! I agree with your
| assessment; I just hope that this is considered to not be in
| breach of the spirit of the PEP. It seems like the PEP
| intended to disallow squatting in terms of pre-emptively
| reserving and hogging names, the way domain squatters do it.
| So hopefully typosquatting prevention for the sake of
| security is considered fine by the admins; especially since
| our project was designated a 'critical project' and stricter
| security measures apply to our maintainers.
| thombles wrote:
| To my knowledge this is the only wrong crate I've ever installed
| due to my own error. It's... not a good feeling to read this
| message, even though the author turned out to be doing me a
| favour. :)
| worewood wrote:
| Why not just add ripgrep as a dependency, effectively making it
| an alias of the original package?
| burntsushi wrote:
| I wouldn't sign off on this personally. It makes auditing
| harder. You see `cargo install rg` somewhere, but you also see
| that `cargo install ripgrep` is what's listed in ripgrep's
| README. So now you wonder, is `cargo install rg` correct? Then
| maybe ripgrep has to add a note about this to the README, and
| maybe you see it, maybe you don't.
|
| Better to just make `cargo install rg` fail so that it never
| worked in the first place. `cargo install ripgrep` is also more
| self-describing and gives you a better search engine query.
| Longwelwind wrote:
| Maybe it's only for me, but I've never liked this of too-smart
| solutions.
|
| Let people do the mistakes once and learn the correct package
| name, instead of relying on a hack and potentially introduce
| confusion later.
| yellowapple wrote:
| Not to mention adding a juicy target for malicious
| shenanigans.
| 3a2d29 wrote:
| This would work, but I think hiding a package behind an alias
| is never a good idea.
| stjohnswarts wrote:
| Nah KISS
| kevincox wrote:
| Would this install the binaries of the dependency to your
| $PATH? I would expect that only the top-level package would be
| "installed" that way.
___________________________________________________________________
(page generated 2022-10-17 23:00 UTC)