Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce standard point for enabling/disabling features #1041

Closed
jlstevens opened this issue Jan 9, 2017 · 12 comments
Closed

Introduce standard point for enabling/disabling features #1041

jlstevens opened this issue Jan 9, 2017 · 12 comments
Assignees
Milestone

Comments

@jlstevens
Copy link
Contributor

jlstevens commented Jan 9, 2017

It would be good to have a convenient place to enable/disable particular holoviews features. This would help by allowing us to encourage uses to use new behavior (for instance the recently enabled changes to layouts) before they are on by default or to re-enable old behaviors for backwards compatibility.

This system should be tied to versions in some way. I've not thought through the API yet, but something like:

hv.enable('1.6') # Enable legacy features from 1.6
hv.enable('1.8') # Enable available future defaults in 1.8
hv.enable({'1.6':['layout'], '1.8':['options_propagation']})

Maybe calling hv.enable() (i.e without arguments) could print a list of options to enable/disable. I think it would be good to introduce this system for 1.7.

@jlstevens jlstevens added this to the v1.7.0 milestone Jan 9, 2017
@jlstevens jlstevens self-assigned this Jan 9, 2017
@philippjfr
Copy link
Member

Agree with the overall proposal, not entirely happy with hv.enable though. Don't think it needs to be in the top-level namespace and enable doesn't really say much. Think I would prefer something like hv.Store.legacy.

@jlstevens
Copy link
Contributor Author

I'm not particularly attached to the name enable but I do feel it should be in the top-level namespace as it applies settings that affect the whole project.

@jbednar
Copy link
Member

jbednar commented Jan 9, 2017

This does seem like a top-level concept to me.

@philippjfr
Copy link
Member

Sure, I'm overruled 😄

@jlstevens
Copy link
Contributor Author

Ok, any suggestions for the name of this thing?

@jbednar
Copy link
Member

jbednar commented Jan 9, 2017

hv.feature?

@jlstevens
Copy link
Contributor Author

I suppose a Feature could be some sort of fancy element, but as it is lower case, that isn't an issue. I would make it plural though so maybe hv.features?

Even then I'm not 100% convinced as it sounds like it is enabling/disabling features whereas it is more about enabling/disabling versions of various features. Need to think about it more.

@jlstevens
Copy link
Contributor Author

How about hv.config?

I quite like this as I can't think of anything else we want to configure other than backwards compatibility settings - everything notebook specific is done by the notebook extension.

@jbednar
Copy link
Member

jbednar commented Jan 23, 2017

Fine by me.

@philippjfr
Copy link
Member

Same here, hv.config seems fine.

@philippjfr philippjfr modified the milestones: v2.0, v1.7.0 Mar 29, 2017
@philippjfr
Copy link
Member

This has now been added, closing.

@philippjfr philippjfr modified the milestones: v1.8, v2.0 Jun 27, 2017
@jlstevens
Copy link
Contributor Author

Just to keep a record, hv.config was introduced in #1518.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants