Need a better way to manage plugins rather than flooding Gemfiles and gemspecs #699

Open
banister opened this Issue Aug 26, 2012 · 7 comments

Comments

Projects
None yet
5 participants
Owner

banister commented Aug 26, 2012

Perhaps making use of pry-debundle and allowing a Gemfile-like section in the .pryrc file.

Owner

ConradIrwin commented Aug 26, 2012

We'll probably want to keep Gemfile support, @rf- and presumably others use
that. I agree it would be nice to have an alternative.

On Saturday, August 25, 2012, John Mair wrote:

Perhaps making use of pry-debundlehttps://github.com/conradirwin/pry-debundleand allowing a Gemfile-like section in the
.pryrc file.


Reply to this email directly or view it on GitHubhttps://github.com/pry/pry/issues/699.

Owner

kyrylo commented Aug 26, 2012

I'm afraid .pryrc is the only solution. But that kills the idea of autoloading of plugins. You have to specify them anyway.

Yeah, I also got tired of including tons of pry plugins in Gemfiles, so hopefully this helps inch things along:

a pry-force-(name) virtual gem wrapper that always loads pry-(name).

This would let Gemfile & .pryrc behavior remain the same; effort would just be a nanogem for each major plugin.

See my already nonconformist pry-awesome_print for a boilerplate example.

Owner

banister commented Sep 18, 2012

@steakknife thanks, however i dont quite understand what you mean. could you flesh out your idea a bit more? thanks :)

Super late-to-the-party after everyone went home...

  • pry-force-awesome_print would hard depend on both pry and awesome_print, require both and set them up with sane config automagickally.
  • pry-awesome_print wouldn't depend on either, just try to require and configure both if neither raised LoadErrors. (would need a semver bump as it currently depends on AP).

Non-default config could be handled in .pryrc

Owner

rf- commented Apr 29, 2014

From #663:

Now we have a lot of plugins available it's become important for the user to manage them properly from within pry. This functionality could be provided by one command or a suite of commands, but the minimum functionality should be:

List which plugins are installed
List which plugins are active.
View a list of all available plugins on rubygems, with descriptions, and their dependencies
Possibly install new plugins
Possibly uninstall plugins
Possibly disable active plugins
Possibly enable deactivated plugins

If we want to allow enabling/disabling plugins, it is important we refactor the plugin system and provide it with a few hooks and a way of defining plugin functionality so that they can be activated/deactivated on demand.

Further, this would allow for the proper treatment of plugins like pry-nav which monkeypatch pry core methods

I'm putting this under the 1.0 milestone; we should at least make some kind of decision about what we want plugins to look like for 1.0.

@rf- rf- added this to the v1.0.0 milestone Apr 29, 2014

Owner

kyrylo commented Mar 4, 2015

So, speaking of this branch, which partially fixes some problems, I must point out that it also implements subcommands (akin to git subcommands).

UPD: Sorry, I was wrong. We already support subcommands :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment