is there a way to refer to the "default" gemset (the standard rbenv gem location) in .rbenv-gemset

[bughit]

I would like for it to be the default "gemset" and for all my gems to be there except for a couple of Rubymine debug gems, different versions of which will live is different gemsets

Something like that is probably doable with an explicit "global" gemset listed first, in .rbenv-gemset, but why create an explicit global gemset when you already have an implicit global gemset with all the gems in it.

if this is not possible, please consider adding it.

[jf]

I see several problems here:

1. how would you name this "implicit" global gemset exactly? and how would you reference it in a gemset?

2. how would you install gems into this implicit global gemset?

Perhaps you can write down the exact instructions that you would execute in a scenario like this to show how it would work for you.

[bughit]

1. The user would not name it or rename it or create it or delete it, it's simply a way to refer to the default rbenv gem location. It's always there and would have a fixed symbolic name, like standard, system, default, implicit, rbenv, global I guess is already taken.

2. If it's listed first in the .rbenv-gemset, I am assuming it becomes the primary, so the default gem install location, would it not? Or am misunderstanding how it works?

the exact scenario, assuming this implicit gemset is called "default"

1. .rbenv-gemset would contain
   default
   alt1

2. all gems would normally get bundle installed into default since it's first and therefore primary

3. I would manually install rubymine debug gems into alt1 (using RBENV_GEMSETS)

4. I would manually install newer/beta versions of rubymine debug gems into alt2

5. Then I can flip between newer/older rubymine debug gems by fippinng alt1/alt2 in .rbenv-gemset

[jf]

2. If it's listed first in the .rbenv-gemset, I am assuming it becomes the primary, so the default gem install location, would it not? Or am misunderstanding how it works?

So my question is does the user need to explicitly name it in .rbenv-gemset in order to use it?

the exact scenario, assuming this implicit gemset is called "default"

1. .rbenv-gemset would contain
   default
   alt1

2. all gems would normally get bundle installed into default since it's first and therefore primary

3. I would manually install rubymine debug gems into alt1 (using RBENV_GEMSETS)

4. I would manually install newer/beta versions of rubymine debug gems into alt2

5. Then I can flip between newer/older rubymine debug gems by fippinng alt1/alt2 in .rbenv-gemset

Thank you for that. It sounds like you're an advanced user, if you know how to use RBENV_GEMSETS. The only difference between the current capability or behaviour of rbenv-gemset and what you propose is that with what you want, you dont need to type one command: rbenv gemset create $RUBY_VERSION default?

[bughit]

Yes you can create your own default gemset, but why have to create something that already exists and is full of gems? All that's missing is an ability to refer to it.

[jf]

full of gems? how would it be full of gems?

[bughit]

How would the default rbenv gem location would be full of gems?

1. Before you start using rbenv-gemset plugin that's where all the gems go
2. Even after you start using rbenv-gemset plugin, that's where all the gems go if you manually install outside of any preoject or in a project that does not use .rbenv-gemset

[jf]

How would the default rbenv gem location would be full of gems?

Mind you, this is not rbenv-gemset at work here. This is simply standard ruby behaviour.

2. Even after you start using rbenv-gemset plugin, that's where all the gems go if you manually install outside of any preoject or in a project that does not use .rbenv-gemset

So basically you want the standard gem install location to be called something like "default". This is going to require some thought:

1. There is already "global". Do I want to be the one to explain to everybody who comes by how "global" works, vs "default"? You can already see how "global" was a mess with Explixitly disable global gemset #59.

2. It would be easier to simply use gemsets to manage things. Have too many gems in your standard gem location? Get another installation of ruby! you've got rbenv, right?

3. What you would like the behaviour to be if default is not named in a .rbenv-gemsets file?

[bughit]

1. I'll try to provide an explanation, for the readme
3. same as now, which I think means that gems are neither installed nor loaded form there, is that correct?

[jf]

3. same as now, which I think means that gems are neither installed nor loaded form there, is that correct?

Try it out and see for yourself.

[bughit]

so it looks like gems are always loaded from "default"

That does not seem ideal (isn't isolation/encapsulation one of the main points) nor is there any control over this. My proposal provides the control, you can choose whether gems are loaded from default by including it and you can choose whether gems are installed to default by making it primary.

I am guessing you won't want to break compat, so that means the "default" gemset would be implicitly included, like global. Perhaps it can get the -global treatment. Then by putting it first explicitly, you'd be making it primary.

Alternatively maybe you'd want to break compat and get rid of all implicit inclusion, global and default. Then global goes away entirely as a "special" gemset, and default takes it's place but with explicit user control.

[jf]

so it looks like gems are always loaded from "default"

from the ruby-installed gem list, yes. That's what the creators of ruby have deemed as "essential", I guess. Or "standard".

In certain cases, these are indeed absolutely essential (see #53 ).

That does not seem ideal (isn't isolation/encapsulation one of the main points) nor is there any control over this.

I can't control how people install gems before coming to rbenv-gemset. If they start using it from the start, all well and good, but if they don't...

My proposal provides the control, you can choose whether gems are loaded from default by including it and you can choose whether gems are installed to default by making it primary.

it'll be adding a requirement that "upgraders" (people who started using rbenv for some time before getting into rbenv-gemset) include "default" into their gemset list if they want to be up and running and productive quickly

I am guessing you won't want to break compat, so that means the "default" gemset would be implicitly included, like global. Perhaps it can get the -global treatment. Then by putting it first explicitly, you'd be making it primary.

I dont know how much of a pain point this would be, that the default gem "set" would get in the way such that you have to do "-default". Can you find support for this?

Alternatively maybe you'd want to break compat and get rid of all implicit inclusion, global and default. Then global goes away entirely as a "special" gemset, and default takes it's place but with explicit user control.

About global, I would love to have it go away as some special gemset. This was before my time as maintainer, and I personally prefer control over convenience.

As for "default" becoming non-special... perhaps. I dont know. How much of a problem is this, really? Can you find some people for whom your proposed change would really be heaven for them (and conversely, the current situation, hell)?

[bughit]

Final words.

When I started this I didn't realize the gems were always loaded from default, but now that I do, it especially makes sense to allow default to be primary because in effect the concept of "default" already half exists. If gems can be loaded from it then gems should be installable to it.

That's simply how I would like to use gemsets, mostly using default with a few small helper gemsets when I need them. If you don't think this has value, well, so be it.