Name change?

[alphapapa]

Hi there,

I just discovered this package by accident. I'm looking forward to trying it... ;) Seriously though, it reminds me of some shell scripts I wrote to do the same thing for Debian packages. Too often I'd install a package to try it out, then forget about it before I decided, and it would sit there taking up space and slowing down dpkg.

Anyway, I was wondering if you would consider changing the name to something like try-package or package-try. It would be far more descriptive and more likely for users to discover it and remember it. try by itself is so ambiguous... :)

Thanks.

[larstvei]

Hi!

Thanks for the feedback. I'll definitely consider it.

The major argument for keeping the name try is that some might have try in their configs (through use-package for instance), and this would brake after a name-change. Another is that try is not just for trying packages, but also for trying out elisp files found on the web (e.g. a snippet from emacswiki). Lastly, I (personally) like short and sweet names, though this in itself does of course not condone an ambiguous name.

On the other hand I completely see your point; it's not a good name and the time might be ripe for a "rebranding". I'll think it over. If I can find a way to go through with a name change without breaking people's configs, then I will most likely do it. If not, I will have to consider if a name-change is worth breaking a few configs.

Let me know if you have any input!

[alphapapa]

Thanks. Yeah, I would say a transition period would be good, maybe 3 months or so? Seems like most people upgrade their packages pretty often.

What I think I'd suggest is, making a new repo for try-package, adding it as a separate package, then uploading a new version of try that does nothing but tell users to install the new package. That way people wouldn't accidentally get stuck using an old version of try because it stops being updated when there's a new package available.

[raxod502]

I feel like you could handle this transition pretty well without introducing backwards incompatibilities. Firstly, MELPA has a feature for old names of a recipe forwarding to the current name. Secondly, you can distribute a file try.el which loads try-package.el, defines aliases for the commands, and then provides the 'try feature. (Optionally, you could print a deprecation warning when try.el is loaded.) That way, old and new configurations continue to work.