Separate ivy and swiper in 2 different repositories

[DamienCassou]

I don't understand why ivy and swiper are in the same repository. Also, when I want the documentation of ivy, I have to go to http://oremacs.com/swiper/. Why do you keep these 2 very different packages together?

[NicolasPetton]

Shouldn't the repo be named ivy, swiper being an "extra" package for ivy the same way there are counsel completions functions?

[NicolasPetton]

Shouldn't the repo be named ivy, swiper being an "extra" package for ivy the same way there are counsel completions functions?

[abo-abo]

The package names formed historically, swiper was the first one.

Logically, swiper, ivy and counsel belong in the same repo, since they depend on each other. It makes it easier for me to track the issues, PR and git history.

I could rename it to ivy, but then people would ask why are swiper and counsel in the ivy repo. I'd rather just keep the historically first name.

[abo-abo]

The package names formed historically, swiper was the first one.

Logically, swiper, ivy and counsel belong in the same repo, since they depend on each other. It makes it easier for me to track the issues, PR and git history.

I could rename it to ivy, but then people would ask why are swiper and counsel in the ivy repo. I'd rather just keep the historically first name.

[NicolasPetton]

Oleh Krehel notifications@github.com writes:

Logically, swiper, ivy and counsel belong in the same repo,
since they depend on each other. It makes it easier for me to track
the issues, PR and git history.

ivy does not depend on the other two, does it?

Nico

[NicolasPetton]

Oleh Krehel notifications@github.com writes:

Logically, swiper, ivy and counsel belong in the same repo,
since they depend on each other. It makes it easier for me to track
the issues, PR and git history.

ivy does not depend on the other two, does it?

Nico

[abo-abo]

ivy does not depend on the other two, does it?

Of course not. But it's convenient to grep around and replace stuff all at once.

[abo-abo]

ivy does not depend on the other two, does it?

Of course not. But it's convenient to grep around and replace stuff all at once.

[justbur]

@abo-abo I don't think the repo name is an issue, since you can figure it out easily enough, but I think it's a bit confusing at first that you have to install swiper to get ivy. Suppose someone says you should try ivy instead of helm. If you go to melpa and search for ivy you don't get any obvious hits. I would suggest making ivy a separate package on melpa. I don't care what the repo name is.

[justbur]

@abo-abo I don't think the repo name is an issue, since you can figure it out easily enough, but I think it's a bit confusing at first that you have to install swiper to get ivy. Suppose someone says you should try ivy instead of helm. If you go to melpa and search for ivy you don't get any obvious hits. I would suggest making ivy a separate package on melpa. I don't care what the repo name is.

[abo-abo]

@justbur

This was the case before: a package ivy existed in MELPA, but there was an issue with building the package in GNU ELPA (with the inter-dependencies, I think). Right now I just merge into GNU ELPA with git subtree merge. I don't want to complicate my workflow, so it must remain a single package in GNU ELPA.

As I recall, when ivy had to be renamed and merged into swiper, I had a week worth of issues from users for whom things stopped working. So if there's any rename to be done, I want it to go smoothly and semi-automatically. I don't want to break people's configs simply in the name of re-organizing stuff.

Situation after the possible rename

Right now it's a bit weird, but things work. If I were to make the rename, there would be:

1. A package ivy-0.8.0 in GNU ELPA, one that provides both swiper.el and counsel.el.
2. Either three separate packages on MELPA: ivy, swiper, and counsel or a single ivy package in MELPA. I'm in favor of the latter option, see below.
3. And of course all the current versions will still be around in user's configs for a long time, before they all update to the new system.
4. I guess swiper-0.7.0 would still just be hanging around on GNU ELPA, I don't know if it's possible to remove all the old versions of a package. All the old releases are still there: http://elpa.gnu.org/packages/swiper.html.

Things to consider for the rename

1. If I rename this repo to https://github.com/abo-abo/ivy, I think Github will automatically redirect from https://github.com/abo-abo/swiper. I'm not sure if it's reliable. And I don't think it's really necessary, provided the packages themselves are renamed in GELPA and MELPA.
2. Is it really advantageous to have 3 whole packages in MELPA for a mere 6k lines of code? The initial consideration was to have the rarely updated core in ivy.el and often updated trunk in counsel.el. So a user could simply install ivy.el and have very rare and small updates. I don't know if the above is important at all to most users. Myself, I find ivy.el pretty bare-bones and I'd expect the user to want all 3 packages anyway. Would it be simpler to just have a single ivy package in MELPA that provides everything and a single package in ELPA that provides everything? Since it has to be a single package in ELPA anyway.
3. In case the decision is to merge everything into a single package, how would it work remove the existing packages from MELPA and have them redirect to the new location? Is there a mechanism for this?

[abo-abo]

@justbur

This was the case before: a package ivy existed in MELPA, but there was an issue with building the package in GNU ELPA (with the inter-dependencies, I think). Right now I just merge into GNU ELPA with git subtree merge. I don't want to complicate my workflow, so it must remain a single package in GNU ELPA.

As I recall, when ivy had to be renamed and merged into swiper, I had a week worth of issues from users for whom things stopped working. So if there's any rename to be done, I want it to go smoothly and semi-automatically. I don't want to break people's configs simply in the name of re-organizing stuff.

Situation after the possible rename

Right now it's a bit weird, but things work. If I were to make the rename, there would be:

1. A package ivy-0.8.0 in GNU ELPA, one that provides both swiper.el and counsel.el.
2. Either three separate packages on MELPA: ivy, swiper, and counsel or a single ivy package in MELPA. I'm in favor of the latter option, see below.
3. And of course all the current versions will still be around in user's configs for a long time, before they all update to the new system.
4. I guess swiper-0.7.0 would still just be hanging around on GNU ELPA, I don't know if it's possible to remove all the old versions of a package. All the old releases are still there: http://elpa.gnu.org/packages/swiper.html.

Things to consider for the rename

1. If I rename this repo to https://github.com/abo-abo/ivy, I think Github will automatically redirect from https://github.com/abo-abo/swiper. I'm not sure if it's reliable. And I don't think it's really necessary, provided the packages themselves are renamed in GELPA and MELPA.
2. Is it really advantageous to have 3 whole packages in MELPA for a mere 6k lines of code? The initial consideration was to have the rarely updated core in ivy.el and often updated trunk in counsel.el. So a user could simply install ivy.el and have very rare and small updates. I don't know if the above is important at all to most users. Myself, I find ivy.el pretty bare-bones and I'd expect the user to want all 3 packages anyway. Would it be simpler to just have a single ivy package in MELPA that provides everything and a single package in ELPA that provides everything? Since it has to be a single package in ELPA anyway.
3. In case the decision is to merge everything into a single package, how would it work remove the existing packages from MELPA and have them redirect to the new location? Is there a mechanism for this?

[justbur]

Right now I just merge into GNU ELPA with git subtree merge. I don't want to complicate my workflow, so it must remain a single package in GNU ELPA.

Fair enough. No need to make things more complicated.

The thing I was responding to is that from what I've seen many people are interested in ivy as an alternative to helm. I've seen that comment more than swiper as a replacement for isearch for instance. That suggests to me that ivy is the most important name of the three, in terms of what people would search for. I think it's easy to understand that helm is the base functionality and all of the helm-xxxx things are tools built on helm. So you can see immediately that you need helm as a dependency for helm-projectile for instance.

I would be in favor of one ivy package. There's not really any downside to installing all of the code at once (it's not like helm where you have to wait for it to build (or whatever it's doing) every time it's upgraded). I think it would also help with third party extensions which are likely to be named ivy-xxxxx.

In case the decision is to merge everything into a single package, how would it work remove the existing packages from MELPA and have them redirect to the new location? Is there a mechanism for this?

Not sure, maybe @purcell could help here.

[justbur]

Right now I just merge into GNU ELPA with git subtree merge. I don't want to complicate my workflow, so it must remain a single package in GNU ELPA.

Fair enough. No need to make things more complicated.

The thing I was responding to is that from what I've seen many people are interested in ivy as an alternative to helm. I've seen that comment more than swiper as a replacement for isearch for instance. That suggests to me that ivy is the most important name of the three, in terms of what people would search for. I think it's easy to understand that helm is the base functionality and all of the helm-xxxx things are tools built on helm. So you can see immediately that you need helm as a dependency for helm-projectile for instance.

I would be in favor of one ivy package. There's not really any downside to installing all of the code at once (it's not like helm where you have to wait for it to build (or whatever it's doing) every time it's upgraded). I think it would also help with third party extensions which are likely to be named ivy-xxxxx.

In case the decision is to merge everything into a single package, how would it work remove the existing packages from MELPA and have them redirect to the new location? Is there a mechanism for this?

Not sure, maybe @purcell could help here.

[purcell]

I also feel like ivy should be a separate package, though of course it can continue to live in the same repo. Our recipe format supports an :old-names key, which allows for redirects on the melpa.org website. There's no concept of "remov[ing] the existing packages from MELPA" because we rebuild all of them from the recipes every few hours anyway.

[purcell]

I also feel like ivy should be a separate package, though of course it can continue to live in the same repo. Our recipe format supports an :old-names key, which allows for redirects on the melpa.org website. There's no concept of "remov[ing] the existing packages from MELPA" because we rebuild all of them from the recipes every few hours anyway.

[ghost]

Just thought I'd weigh in.

Either three separate packages on MELPA: ivy, swiper, and counsel or a single ivy package in MELPA. I'm in favor of the latter option, see below.

I agree that it could be beneficial to rename the package to ivy based on its popularity and making it easier to find for new users. I also think it would be fine to merge all three into a single package. I use ivy and counsel, but not swiper, but having all three installed is not a big deal if it makes development easier. Emacs is everything but the kitchen sink anyways ;-).

It's also worth mentioning that all three share data structures and function signatures, and MELPA builds are non-atomic, meaning that having three separate packages would make problems like #404 occur more often. This could maybe be changed on MELPA's side though.

I guess swiper-0.7.0 would still just be hanging around on GNU ELPA, I don't know if it's possible to remove all the old versions of a package.

In case the decision is to merge everything into a single package, how would it work remove the existing packages from MELPA and have them redirect to the new location? Is there a mechanism for this?

If it's not possible to remove it by name, it might be useful to push a final update to GNU ELPA swiper which only has the function of installing the latest ivy version from GNU ELPA. This would make transitioning seamless for users as well. It could also make sense to do this for MELPA.

[ghost]

Just thought I'd weigh in.

Either three separate packages on MELPA: ivy, swiper, and counsel or a single ivy package in MELPA. I'm in favor of the latter option, see below.

I agree that it could be beneficial to rename the package to ivy based on its popularity and making it easier to find for new users. I also think it would be fine to merge all three into a single package. I use ivy and counsel, but not swiper, but having all three installed is not a big deal if it makes development easier. Emacs is everything but the kitchen sink anyways ;-).

It's also worth mentioning that all three share data structures and function signatures, and MELPA builds are non-atomic, meaning that having three separate packages would make problems like #404 occur more often. This could maybe be changed on MELPA's side though.

I guess swiper-0.7.0 would still just be hanging around on GNU ELPA, I don't know if it's possible to remove all the old versions of a package.

In case the decision is to merge everything into a single package, how would it work remove the existing packages from MELPA and have them redirect to the new location? Is there a mechanism for this?

If it's not possible to remove it by name, it might be useful to push a final update to GNU ELPA swiper which only has the function of installing the latest ivy version from GNU ELPA. This would make transitioning seamless for users as well. It could also make sense to do this for MELPA.

[joelmccracken]

This confuses me every time I want to try using ivy, and is one of the things that makes me hesitate to use it, for better or worse.

[joelmccracken]

This confuses me every time I want to try using ivy, and is one of the things that makes me hesitate to use it, for better or worse.

[abo-abo]

@DamienCassou OK, the change in MELPA went through, and the rename in GNU ELPA as well. I don't think a Github repository rename is necessary at this point.

[abo-abo]

@DamienCassou OK, the change in MELPA went through, and the rename in GNU ELPA as well. I don't think a Github repository rename is necessary at this point.

[manuel-uberti]

Thanks for this.

[manuel-uberti]

Thanks for this.

[DamienCassou]

thank you very much

[DamienCassou]

thank you very much