Re: Re: pyrus woes

It might, but I think the unintended consequences could be extensive and will require more bloat than it would seem to mitigate. Just preventing pyrus from dropping a registry on read ops is quite extensive and required a whole slew of regression tests. I made it easy to pass in a non-default directory, and there is nothing preventing someone with Till's requirements from making a 1-line script to do this: #!/bin/sh /path/to/pyrus /path/to/here $* And ./pyrus dosomething Which would be far safer for the most common use case, a single install or user/system install. In other words: What Till is requesting is already possible with a 1-line script and no changes to pyrus, and it would add lots of code and ambiguity/magic to pyrus to implement, so I don't think the benefits outweigh the costs. As always, if you can prove me wrong, by all means, do so and make the changes, but please do try to consider the problematic cases such as trying to manage things with "pyrus install blah" and accidentally being in a directory that happens to have a pyrus installation, such as an embedded install within a larger project. Pyrus would report success and the package would not be installed where the user expects. This is a dangerous situation, I hope my argument makes sense. Greg On Jul 8, 2010, at 2:07 PM, Brett Bieber <brett.bieber@gmail.com> wrote: > On Thu, Jul 8, 2010 at 11:51 AM, Gregory Beaver <greg@chiaraquartet.net> wrote: >> Too much magic. >> >> Is it really so hard to >> >> pyrus . install foo >> >> ? >> >> Don't forget the majority of pear-general newbie problems come from >> things going in a different location than expected >> >> Greg > > Yes, I'd agree this would be problematic to have this be the default > setting, and not ask the user where they'd like to install packages on > first run. But if I set my_pear_path to something that included a ., I > would expect that to work. > > -- > Brett Bieber