Re: Emacs-Guix released outside from Guix

[Alex Kost]

Thompson, David (2017-01-06 10:50 -0500) wrote:

> Hey Alex,
>
> On Thu, Dec 15, 2016 at 9:48 AM, Alex Kost  wrote:
>> Hello, I've been working on Emacs interface outside from the Guix repo
>> for some time, I mean I'm not going to maintain it inside Guix, sorry :-(
>
> Sorry to hear about this.  This move will make it difficult for me to
> use guix.el moving forward due to inevitable API incompatibilities, so
> I've decided to just stop using it.

As you wish :-)

> I hope that one day this code
> will come back into the guix source tree.

Well, anything can happen, but it's highly unlikely.

-- 
Alex

Re: Emacs-Guix released outside from Guix

[Thompson, David]

Hey Alex,

On Thu, Dec 15, 2016 at 9:48 AM, Alex Kost  wrote:
> Hello, I've been working on Emacs interface outside from the Guix repo
> for some time, I mean I'm not going to maintain it inside Guix, sorry :-(

Sorry to hear about this.  This move will make it difficult for me to
use guix.el moving forward due to inevitable API incompatibilities, so
I've decided to just stop using it.  I hope that one day this code
will come back into the guix source tree.

- Dave

Re: Emacs-Guix released outside from Guix

[myglc2]

On 12/18/2016 at 11:32 Ludovic Courtès writes:

> Hi Alex,
>
> Alex Kost  skribis:
>
>> Ludovic Courtès (2016-12-15 18:39 +0100) wrote:
>>
[...]
>
>> I always feel uncomfortable to send patches or to push commits to the
>> Guix repo.  I can't explain it properly, it's just painful all the
>> time; but more importantly, it slowed down the development, as I often
>> decided not to do small changes.  Contrary, I made more commits to the
>> Emacs-Guix source tree in the past month, than to the Guix repo during
>> the whole year.
>
> I have the same questions as John: what is it that made you feel
> uncomfortable?  I stated clearly multiple times that you are effectively
> “sudoer” on this code.
>
> Let’s reflect on this for all the future Alexes that come around.  If
> you are in my position, what do you do to make it so that the next Alex
> feels comfortable and happy with this workflow?  What does it take to
> avoid an “Alexit”?  :-)
>
> That’s an honest question: I cannot state what I did wrong, but I’d like
> to learn so it doesn’t happen again.

Hi Ludo’, 

I really don't see the downside to emacs-guix being moved out of the
guix repo.  From the user's point of view, it doesn't matter where the
code lives, as long as it continues to be expertly developed for the
benefit of guix users.

It is true that emacs-guix code changes will no longer pass thru the
guix QC and review process, but you control which emacs-guix code
"ships" with guix via the package definition. So there is no loss of
control.

If an approach like this provides a more comfortable and productive
working environment for a contributor, it seems like a win-win for Guix
users.  Maybe there are other situations where this approach could
address developer issues.

In the case of emacs-guix, which is so closely bound to Guix, I suggest
that you make it a "guix endorsed package."  This would clarify the
situation for guix users. In practice, one thing this could mean would
be for you to host guix-emacs discussion on guix mailing lists, if Alex
is so inclined.

Best, - George

Re: Emacs-Guix released outside from Guix

[myglc2]

On 12/22/2016 at 12:15 Alex Kost writes:

> myglc2 (2016-12-21 19:18 -0500) wrote:
>
>> Have you decided re feedback/support? github issues? mailing list?
>
> Whatever seems appropriate to you: issues or pull requests on
> github/notabug, or mailing me directly is OK.  As for using guix-devel
> mailing list, I think it's not a suitable place, I would like to avoid
> polluting this list with Emacs-Guix stuff.

I think you should provide guidance about this in your README.  A
designated mailing list would be good because it will provide an archive
of questions and answers.

I think you should reconsider "polluting this list" and I think you
should continue using the Guix lists if Ludo and others are
agreeable. My reasoning is as follows:

- 99.9% of your users are on these lists

- emacs-guix remains an essential a part of Guix

- from a user's point of view, its being in a separate repo is a purely
  technical detail

>> Many thanks for continuing to make emacs-guix cooler and cooler!
>
> Thanks, make sure to check "M-x guix-help", if you have not yet.

I did, very cool.

> BTW I'm going to release 0.2.1 in a few days.  It will have "M-x
> guix-about" command, which is not very useful but it's
> "fancy"... well, I'll make an announcement about it :-)

Looking forward ;-)

Re: Emacs-Guix released outside from Guix

[Alex Kost]

myglc2 (2016-12-21 19:18 -0500) wrote:

> On 12/17/2016 at 12:13 Alex Kost writes:
>
>> I have committed 'emacs-guix' package, so after "guix pull" or if you
>> use the git checkout, you may try it with:
>>
>>   guix package -i emacs-guix
>
> Hi Alex,
>
> Tried this on GuixSD 0.12.0 from git and I dig it!
>
> When I google 'guix emacs github' the top hit is ...
>
> GitHub - alezost/guix.el: (OBSOLETE) Emacs interface for Guix ...
>
> ... Which is cool, but '(OBSOLETE)' is odd. Maybe it will fix itself?

I'm sure it will fix itself.  I changed this description a week ago (it
was "OBSOLETE" for more than a year); apparently, google does not know
about it yet.

> Have you decided re feedback/support? github issues? mailing list?

Whatever seems appropriate to you: issues or pull requests on
github/notabug, or mailing me directly is OK.  As for using guix-devel
mailing list, I think it's not a suitable place, I would like to avoid
polluting this list with Emacs-Guix stuff.

> Many thanks for continuing to make emacs-guix cooler and cooler!

Thanks, make sure to check "M-x guix-help", if you have not yet.  BTW
I'm going to release 0.2.1 in a few days.  It will have "M-x guix-about"
command, which is not very useful but it's "fancy"... well, I'll make an
announcement about it :-)

Re: Emacs-Guix released outside from Guix

[myglc2]

On 12/17/2016 at 12:13 Alex Kost writes:

> I have committed 'emacs-guix' package, so after "guix pull" or if you
> use the git checkout, you may try it with:
>
>   guix package -i emacs-guix

Hi Alex,

Tried this on GuixSD 0.12.0 from git and I dig it!

When I google 'guix emacs github' the top hit is ...

GitHub - alezost/guix.el: (OBSOLETE) Emacs interface for Guix ...

... Which is cool, but '(OBSOLETE)' is odd. Maybe it will fix itself?

Have you decided re feedback/support? github issues? mailing list?

Many thanks for continuing to make emacs-guix cooler and cooler!

-George

Re: Emacs-Guix released outside from Guix

[Ludovic Courtès]

Howdy,

Thanks for taking the time to explain.

Make sure to let us know what new things happen in Emacs-Guix, you know
it has its fan club here!  :-)

Ludo’.

Re: Emacs-Guix released outside from Guix

[Alex Kost]

Ludovic Courtès (2016-12-18 11:32 +0100) wrote:

> Hi Alex,
>
> Alex Kost  skribis:
>
>> Ludovic Courtès (2016-12-15 18:39 +0100) wrote:
>>
>>> Hi Alex!
>>>
>>> Alex Kost  skribis:
>>>
 Hello, I've been working on Emacs interface outside from the Guix repo
 for some time, I mean I'm not going to maintain it inside Guix, sorry :-(

 The main reason, is, well, inconvenience for me: I don't like to bother
 people with patches, etc.  I tried to explain it at
 .
>>>
>>> As someone who’s always trusted you to do the right thing, I’m of course
>>> disappointed that we Guix folks didn’t get notified nor consulted before
>>> the fact.  I would also have loved a reply to my message back then¹.
>>> That’s your choice though.
>>>
>>> ¹ https://lists.gnu.org/archive/html/guix-devel/2016-07/msg01110.html
>>
>> I'm sorry for not answering, I thought I was clear at the time.
>
> I thought I was clear too, that message called for your feedback (and
> this one does too!).  Dialog is a two-way street.

But I answered this time!  Sorry if I wasn't clear enough, I tried to
explain my reasons several times, but I can try again.

>> I always feel uncomfortable to send patches or to push commits to the
>> Guix repo.  I can't explain it properly, it's just painful all the
>> time; but more importantly, it slowed down the development, as I often
>> decided not to do small changes.  Contrary, I made more commits to the
>> Emacs-Guix source tree in the past month, than to the Guix repo during
>> the whole year.
>
> I have the same questions as John: what is it that made you feel
> uncomfortable?  I stated clearly multiple times that you are effectively
> “sudoer” on this code.

It's not enough for me: developing an own project is incomparably easier
for me than participating in other people's project.

> Let’s reflect on this for all the future Alexes that come around.  If
> you are in my position, what do you do to make it so that the next Alex
> feels comfortable and happy with this workflow?  What does it take to
> avoid an “Alexit”?  :-)
>
> That’s an honest question: I cannot state what I did wrong, but I’d like
> to learn so it doesn’t happen again.

You did nothing wrong!  It's a nature of such Alexes: we don't like to
communicate with people and we try to avoid it as much as possible.

>>> This change will prevent joint feature development (updating
>>> completions, ‘emacs-build-system’ and how it interacts with the Emacs
>>> UI, M-x guix, cross-cutting changes to the UI, and so on).  This isn’t
>>> good news for users.
>>>
>>> Breakage will occasionally occur as the Guix APIs change, which will
>>> make us all a bit sad.  What are your thoughts?
>>
>> Well, I was going to make a release and to update the 'emacs-guix'
>> package after fixing such a breakage.  Actually this way doesn't look
>> worse for me: when breakages happened in the past, the only way to fix
>> it was to update 'guix-devel' package.
>
> That will be even harder with separate projects.
>
> What about joint feature development (see above)?

Well, when I will notice some related change in Guix, I will do an
according change in Emacs-Guix.  Or someone else will report about it.
If no one will notice or report, then it does not matter.

 So I'd like to add 'emacs-guix' package (the current patchset) and to
 remove it from the Guix source tree, if you don't mind.
>>>
>>> I think “if you don’t mind” is misplaced.
>>
>> No, it's not misplaced; not sure what you mean.
>
> Saying “if you don’t mind” for a decision that is effectively imposed on
> others without discussion is harsh, to put it mildly.

When I wrote "I'd like ... if you don't mind", I politely tried to ask
for a permission to add 'emacs-guix' package, as not allowing me to do
that was one of the possible answers.  I didn't discuss my decision
because I don't like discussions.  Besides, it's a one man's self-willed
decision, how other people could change it without tortures?

[...]
> Pardon me for being grumpy, I’m just feeling sad and frustrated.

No problems, it's not a disaster after all.  If you still wish to use
it, you can just install it as you install other Emacs packages.

-- 
Alex

Re: Emacs-Guix released outside from Guix

[Alex Kost]

John Darrington (2016-12-17 10:00 +0100) wrote:

> On Sat, Dec 17, 2016 at 11:38:13AM +0300, Alex Kost wrote:
>
>  > It would be a great loss and a technical hindrance if guix.el was 
> moved
>  > out of Guix.  I don???t want that to happen, so let me know what 
> the
>  > ransom should be!  ;-)
>
>  There shouldn't be any ransom!  I just didn't feel I had enough freedom
>  when I was working on it inside Guix.
>
>
> Could you elaborate here?  What circumstances made you feel this way?

There are no any circumstances.  It's just that when you maintain your
own project, you can do whatever seems appropriate to you; while with a
community-driven (I don't know a correct term) project, you have to…
well, to communicate – the thing I don't like quite a lot.  So it's not
a Guix community problem!

> Have there been specific events which made you feel your freedom was
> being limited?

No, not at all!  It's just my attitude as I tried to explain.

> What would you have liked to have seen done differently?

Well, I agree with Pjotr's points.  I think the most important is that
all the existing rules make a very high barrier to overcome for the
potential contributors.  I'm not talking about myself, I'm fine with the
rules, but I see how all these guidelines, coding styles and sending
patches to the mailing list can scare people.

But all this has nothing to do with separating Emacs-Guix.  It's just my
egoism: I want to push commits without discussing (or simple sending
patches).

-- 
Alex

Re: Emacs-Guix released outside from Guix - or why I am not sending patches in

[Pjotr Prins]

On Sun, Dec 18, 2016 at 01:47:18PM -0200, Adonay Felipe Nogueira wrote:
> I suspect that he's more used to have "push" permissions to repositories
> instead of submitting patches.

In principle that should not stop working you on your own branch. You
can push and collect your commits into a compiled patch later. That
does not stop the flow of work.

> I, personally, like to work with patches because this allows me to
> submit them directly to people involved in the project in cases the
> project in question requires non-(free/libre) software (written in
> JavaScript) in order to submit things (of course, I'm **not** talking
> about Guix). Also, patch submissions don't require accounts in such
> places as long as you have a way to contact at least one developer by
> email.
> 
> Also, I also like patches because people can state their opinions about
> what I do and even give me some improvement hints instead of having to
> do various push requests in order to make such improvements.

Sure. It can be a learning process which is great. I tried. There are
three problems (also with patches committed for packages):

1. The author may not agree with the imposed strictness or rules of
   patches

2. The turnaround of accepting patches can be a long time

3. Fixing patches on things you don't agree on (or see the importance
   of) is tedious. Very tedious.

That is why I stopped. I rather spend my time coding and documenting.
Personally I also think the threshold is too high to newcomers. 

Obviously others disagree with the above. I may be more sloppy in my
way of coding. I think that if code reads well it is acceptable. I
don't reject things because of spacing or lack comments. I don't
reject things because they are suboptimal (I should stop being a GSoC
mentor if that was the case). I believe that code can be changed and
improved incrementally both by the author and by others. I don't care
others see my short comings. In other words, I am one who plays by his
own rules.

In short, *I* know why *I* am not sending patches in. Even though I
have a long list of packages that *could* go in and arguably should.

This is my annual message on why I think the process may be
improved ;). Maybe we should have a 'sloppy' branch for people like
me. guix channels may help people like me too. I am convinced we could
have double the growth if we were good at attracting and retaining
contributions.

Guix will succeed. I am not arguing we should compromise for
correctness on trunk. But there ought to be ways to help sloppy
contributors ;). Otherwise I'll never contribute to a GNU project. If
the project does not care - who am I to care?

Pj.

-- 

Re: Emacs-Guix released outside from Guix

[Adonay Felipe Nogueira]

I suspect that he's more used to have "push" permissions to repositories
instead of submitting patches.

I, personally, like to work with patches because this allows me to
submit them directly to people involved in the project in cases the
project in question requires non-(free/libre) software (written in
JavaScript) in order to submit things (of course, I'm **not** talking
about Guix). Also, patch submissions don't require accounts in such
places as long as you have a way to contact at least one developer by
email.

Also, I also like patches because people can state their opinions about
what I do and even give me some improvement hints instead of having to
do various push requests in order to make such improvements.

Re: Emacs-Guix released outside from Guix

[Pjotr Prins]

On Sat, Dec 17, 2016 at 11:19:57AM +0300, Alex Kost wrote:
> I'm sorry for not answering, I thought I was clear at the time.  I
> always feel uncomfortable to send patches or to push commits to the Guix
> repo.  I can't explain it properly, it's just painful all the time; but
> more importantly, it slowed down the development, as I often decided not
> to do small changes.  Contrary, I made more commits to the Emacs-Guix
> source tree in the past month, than to the Guix repo during the whole
> year.

Alex, I completely understand. The demands on patches are high and I
have stopped submitting myself even though I work on Guix all the
time. Best is to have your own tree. Tying versions to Guix is trivial
- that is the point of Guix, rather ;).

Making emacs-guix a Guix package is a fine alternative. If someone
finds it that important to host on main he/she can still do that, but
I have trouble seeing the need.

Pj.

Re: Emacs-Guix released outside from Guix

[Ludovic Courtès]

Hi Alex,

Alex Kost  skribis:

> Ludovic Courtès (2016-12-15 18:39 +0100) wrote:
>
>> Hi Alex!
>>
>> Alex Kost  skribis:
>>
>>> Hello, I've been working on Emacs interface outside from the Guix repo
>>> for some time, I mean I'm not going to maintain it inside Guix, sorry :-(
>>>
>>> The main reason, is, well, inconvenience for me: I don't like to bother
>>> people with patches, etc.  I tried to explain it at
>>> .
>>
>> As someone who’s always trusted you to do the right thing, I’m of course
>> disappointed that we Guix folks didn’t get notified nor consulted before
>> the fact.  I would also have loved a reply to my message back then¹.
>> That’s your choice though.
>>
>> ¹ https://lists.gnu.org/archive/html/guix-devel/2016-07/msg01110.html
>
> I'm sorry for not answering, I thought I was clear at the time.

I thought I was clear too, that message called for your feedback (and
this one does too!).  Dialog is a two-way street.

> I always feel uncomfortable to send patches or to push commits to the
> Guix repo.  I can't explain it properly, it's just painful all the
> time; but more importantly, it slowed down the development, as I often
> decided not to do small changes.  Contrary, I made more commits to the
> Emacs-Guix source tree in the past month, than to the Guix repo during
> the whole year.

I have the same questions as John: what is it that made you feel
uncomfortable?  I stated clearly multiple times that you are effectively
“sudoer” on this code.

Let’s reflect on this for all the future Alexes that come around.  If
you are in my position, what do you do to make it so that the next Alex
feels comfortable and happy with this workflow?  What does it take to
avoid an “Alexit”?  :-)

That’s an honest question: I cannot state what I did wrong, but I’d like
to learn so it doesn’t happen again.

>> This change will prevent joint feature development (updating
>> completions, ‘emacs-build-system’ and how it interacts with the Emacs
>> UI, M-x guix, cross-cutting changes to the UI, and so on).  This isn’t
>> good news for users.
>>
>> Breakage will occasionally occur as the Guix APIs change, which will
>> make us all a bit sad.  What are your thoughts?
>
> Well, I was going to make a release and to update the 'emacs-guix'
> package after fixing such a breakage.  Actually this way doesn't look
> worse for me: when breakages happened in the past, the only way to fix
> it was to update 'guix-devel' package.

That will be even harder with separate projects.

What about joint feature development (see above)?

>>> So I'd like to add 'emacs-guix' package (the current patchset) and to
>>> remove it from the Guix source tree, if you don't mind.
>>
>> I think “if you don’t mind” is misplaced.
>
> No, it's not misplaced; not sure what you mean.

Saying “if you don’t mind” for a decision that is effectively imposed on
others without discussion is harsh, to put it mildly.

>> I’ll let you take care of the actual removal, along with update to the
>> Texinfo cross-references and doc/htmlxref.cnf (assuming the manual will
>> be available on-line.)
>
> Ahem, it will not, at least not soon.
>
>> I think it would help users to keep
>> cross-references between the two manuals.
>
> Emacs-Guix manual has many links to the Guix manual, but I think a
> single mention of Emacs-Guix in the Guix manual will be enough.  I have
> not looked at updating cross-references in the Guix manual yet, though.

Sadness.  I think users won’t be happier.  :-/

Pardon me for being grumpy, I’m just feeling sad and frustrated.

Ludo’.

Re: Emacs-Guix released outside from Guix

[Alex Kost]

I have committed 'emacs-guix' package, so after "guix pull" or if you
use the git checkout, you may try it with:

  guix package -i emacs-guix

Just make sure it has a priority over the elisp code from Guix.
"M-x list-load-path-shadows" should help you to figure it out.

Now a bit about the changes.

1. At first, there are 2 new commands:

- M-x guix-help

  I think it may be the most useful command as it shows a summary of all
  the rest available commands.

- M-x guix-profiles

  It displays a list of your Guix profiles.  It's probably not very
  useful if you have a single profile, but if you manage multiple
  profiles, it can be really helpful (well, it's my favourite command as
  I use several profiles).  To add more profiles, set 'guix-profiles'
  variable.

  In this list you can display packages/generations with "P"/"G" keys.
  See also the manual entry: (info "(emacs-guix) Profiles")

2. Secondly, you may be surprised that RET does not display packages
anymore in a list of generations (M-x guix-generations) or licenses (M-x
guix-licenses).  Now "P" key can be used anywhere (where appropriate,
i.e. in a list of profiles, generations, licenses or locations) to
display packages.

3. Also I should mention that 'guix-devel-mode' and
'guix-build-log-minor-mode' are not enabled in scheme/shell buffers by
default.  If you still wish to have them enabled, use:

  (add-hook 'scheme-mode-hook 'guix-devel-mode)
  (add-hook 'shell-mode-hook 'guix-build-log-minor-mode)

in your emacs config.

4. The rest changes are either visible or internal or not important.
You may look at NEWS file for more or less the full list of changes:
.

Thanks for reading this far :-)

-- 
Alex

Re: Emacs-Guix released outside from Guix

[John Darrington]

On Sat, Dec 17, 2016 at 11:38:13AM +0300, Alex Kost wrote:

 > It would be a great loss and a technical hindrance if guix.el was 
moved
 > out of Guix.  I don???t want that to happen, so let me know what the
 > ransom should be!  ;-)
 
 There shouldn't be any ransom!  I just didn't feel I had enough freedom
 when I was working on it inside Guix.


Could you elaborate here?  What circumstances made you feel this way?  Have 
there
been specific events which made you feel your freedom was being limited?  What
would you have liked to have seen done differently?

J'
 
 

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: Emacs-Guix released outside from Guix

[Alex Kost]

Ricardo Wurmus (2016-12-16 01:37 +0100) wrote:

> Hi Alex,
>
> Ludovic Courtès  writes:
>
>> Alex Kost  skribis:
>>
>>> Hello, I've been working on Emacs interface outside from the Guix repo
>>> for some time, I mean I'm not going to maintain it inside Guix, sorry :-(
>>>
>>> The main reason, is, well, inconvenience for me: I don't like to bother
>>> people with patches, etc.  I tried to explain it at
>>> .
>>
>> As someone who’s always trusted you to do the right thing, I’m of course
>> disappointed that we Guix folks didn’t get notified nor consulted before
>> the fact.  I would also have loved a reply to my message back then¹.
>> That’s your choice though.
>>
>> ¹ https://lists.gnu.org/archive/html/guix-devel/2016-07/msg01110.html
>
> First of all, let me tell you that I really appreciate your work on
> guix.el!  It’s excellent and makes me feel even more at home in Emacs.
>
> I whole-heartedly second what Ludo wrote and just now and back then:
>
> It would be a great loss and a technical hindrance if guix.el was moved
> out of Guix.  I don’t want that to happen, so let me know what the
> ransom should be!  ;-)

There shouldn't be any ransom!  I just didn't feel I had enough freedom
when I was working on it inside Guix.

> We’d love for guix.el to stay.  You can already modify the code as you
> deem appropriate without having to worry about a veto from any of us.

Sorry, but I have already pushed too much effort making it a separate
project, and it has changed quite a lot comparing to what we have in a
Guix repo.

>> Breakage will occasionally occur as the Guix APIs change, which will
>> make us all a bit sad.  What are your thoughts?
>
> This is the biggie for me.  Having the Emacs interface so closely
> integrated with the rest of Guix ensured that we wouldn’t have to worry
> about breakage.

How could we be ensured?  When a breakage happened in the past, an
according fix had to be done in the guix repo, and it wasn't available
for users until updating 'guix-devel' package.  Now when a breakage will
happen, an according fix will be done in the emacs-guix repo, and it
will be available for MELPA/Quelpa users right away.

> In my opinion this move increases the friction for the
> users that most care about guix.el for the dubious improvement of
> offering a slimmer guix.el to people who … don’t use Guix.

People can use Guix, but they can still prefer to install Emacs packages
via elpa, not via Guix.

>> I’ll let you take care of the actual removal, along with update to the
>> Texinfo cross-references and doc/htmlxref.cnf (assuming the manual will
>> be available on-line.)  I think it would help users to keep
>> cross-references between the two manuals.
>>
>> We need to see what Ricardo thinks and whether or not this can be done
>> before 0.12, which is slated for sometime next week.
>
> Yes, I’ll start preparing for the release (going through the motions) on
> the weekend, so that the actual tagging and uploading can happen on the
> 20th (busy on the 19th) if all goes well.
>
> If you go through with the move please double check that the Guix
> sources are in a state that’s ready for release.  It would be terrible
> to have a botched release.  (Frankly, I’m a little uncomfortable about
> such a big change right before the release, but maybe I’m just being
> nervous about doing the release myself this time…)

I'm going to send "removal" patches after the release.  BTW thank you
for taking care of the release!

-- 
Alex

Re: Emacs-Guix released outside from Guix

[Alex Kost]

Ludovic Courtès (2016-12-15 18:39 +0100) wrote:

> Hi Alex!
>
> Alex Kost  skribis:
>
>> Hello, I've been working on Emacs interface outside from the Guix repo
>> for some time, I mean I'm not going to maintain it inside Guix, sorry :-(
>>
>> The main reason, is, well, inconvenience for me: I don't like to bother
>> people with patches, etc.  I tried to explain it at
>> .
>
> As someone who’s always trusted you to do the right thing, I’m of course
> disappointed that we Guix folks didn’t get notified nor consulted before
> the fact.  I would also have loved a reply to my message back then¹.
> That’s your choice though.
>
> ¹ https://lists.gnu.org/archive/html/guix-devel/2016-07/msg01110.html

I'm sorry for not answering, I thought I was clear at the time.  I
always feel uncomfortable to send patches or to push commits to the Guix
repo.  I can't explain it properly, it's just painful all the time; but
more importantly, it slowed down the development, as I often decided not
to do small changes.  Contrary, I made more commits to the Emacs-Guix
source tree in the past month, than to the Guix repo during the whole
year.

>> There are 2 more reasons above that:
>>
>> - I'd like to make it available on MELPA (people asked about it several
>>   times in the past);
>
> This is surprising: I’d expect Guix users to install it with Guix, and
> non-Guix users to, well, not care about Guix.

It's not surprising for me: there are people who prefer to install Emacs
packages using Emacs build system, so providing this way to install
"guix.el" seems the right thing for me.

>> - Currently, to be able to use it on non-GuixSD system, a user has to
>>   install 'guix' package into their profile.  This has never looked good
>>   to me (installing a whole guix only for a small part of it). I would
>>   prefer to make "guix package -i emacs-guix" possible instead.
>
> OK.
>
> This change will prevent joint feature development (updating
> completions, ‘emacs-build-system’ and how it interacts with the Emacs
> UI, M-x guix, cross-cutting changes to the UI, and so on).  This isn’t
> good news for users.
>
> Breakage will occasionally occur as the Guix APIs change, which will
> make us all a bit sad.  What are your thoughts?

Well, I was going to make a release and to update the 'emacs-guix'
package after fixing such a breakage.  Actually this way doesn't look
worse for me: when breakages happened in the past, the only way to fix
it was to update 'guix-devel' package.

>> So I'd like to add 'emacs-guix' package (the current patchset) and to
>> remove it from the Guix source tree, if you don't mind.
>
> I think “if you don’t mind” is misplaced.

No, it's not misplaced; not sure what you mean.

>> I'm also sending the following patches:
>>
>> [PATCH 1/2] gnu: Add emacs-bui.
>> [PATCH 2/2] gnu: Add emacs-guix.
>
> OK!

Thanks!  Applied.

> I’ll let you take care of the actual removal, along with update to the
> Texinfo cross-references and doc/htmlxref.cnf (assuming the manual will
> be available on-line.)

Ahem, it will not, at least not soon.

> I think it would help users to keep
> cross-references between the two manuals.

Emacs-Guix manual has many links to the Guix manual, but I think a
single mention of Emacs-Guix in the Guix manual will be enough.  I have
not looked at updating cross-references in the Guix manual yet, though.

> We need to see what Ricardo thinks and whether or not this can be done
> before 0.12, which is slated for sometime next week.

I think this removal can be made later.

> Keep up the great Emacs work.  Long live guix.el!

Thanks, I keep up.

-- 
Alex

Re: Emacs-Guix released outside from Guix

[Alex Kost]

Ludovic Courtès (2016-12-16 17:44 +0100) wrote:

> Howdy!
>
> Ricardo Wurmus  skribis:
>
>> If you go through with the move please double check that the Guix
>> sources are in a state that’s ready for release.  It would be terrible
>> to have a botched release.  (Frankly, I’m a little uncomfortable about
>> such a big change right before the release, but maybe I’m just being
>> nervous about doing the release myself this time…)
>
> It’s fine to postpone the change until after the release if we’re afraid
> of last-minute breakage (which is not unlikely).

I agree, removing "guix.el" code and related changes can happen later,
no hurry about it, thanks!

-- 
Alex

Re: Emacs-Guix released outside from Guix

[Ludovic Courtès]

Howdy!

Ricardo Wurmus  skribis:

> If you go through with the move please double check that the Guix
> sources are in a state that’s ready for release.  It would be terrible
> to have a botched release.  (Frankly, I’m a little uncomfortable about
> such a big change right before the release, but maybe I’m just being
> nervous about doing the release myself this time…)

It’s fine to postpone the change until after the release if we’re afraid
of last-minute breakage (which is not unlikely).

Ludo’.

Re: Emacs-Guix released outside from Guix

[Ricardo Wurmus]

Hi Alex,

Ludovic Courtès  writes:

> Alex Kost  skribis:
>
>> Hello, I've been working on Emacs interface outside from the Guix repo
>> for some time, I mean I'm not going to maintain it inside Guix, sorry :-(
>>
>> The main reason, is, well, inconvenience for me: I don't like to bother
>> people with patches, etc.  I tried to explain it at
>> .
>
> As someone who’s always trusted you to do the right thing, I’m of course
> disappointed that we Guix folks didn’t get notified nor consulted before
> the fact.  I would also have loved a reply to my message back then¹.
> That’s your choice though.
>
> ¹ https://lists.gnu.org/archive/html/guix-devel/2016-07/msg01110.html

First of all, let me tell you that I really appreciate your work on
guix.el!  It’s excellent and makes me feel even more at home in Emacs.

I whole-heartedly second what Ludo wrote and just now and back then:

It would be a great loss and a technical hindrance if guix.el was moved
out of Guix.  I don’t want that to happen, so let me know what the
ransom should be!  ;-)

We’d love for guix.el to stay.  You can already modify the code as you
deem appropriate without having to worry about a veto from any of us.

> Breakage will occasionally occur as the Guix APIs change, which will
> make us all a bit sad.  What are your thoughts?

This is the biggie for me.  Having the Emacs interface so closely
integrated with the rest of Guix ensured that we wouldn’t have to worry
about breakage.  In my opinion this move increases the friction for the
users that most care about guix.el for the dubious improvement of
offering a slimmer guix.el to people who … don’t use Guix.

I feel like I’m missing something here.

> I’ll let you take care of the actual removal, along with update to the
> Texinfo cross-references and doc/htmlxref.cnf (assuming the manual will
> be available on-line.)  I think it would help users to keep
> cross-references between the two manuals.
>
> We need to see what Ricardo thinks and whether or not this can be done
> before 0.12, which is slated for sometime next week.

Yes, I’ll start preparing for the release (going through the motions) on
the weekend, so that the actual tagging and uploading can happen on the
20th (busy on the 19th) if all goes well.

If you go through with the move please double check that the Guix
sources are in a state that’s ready for release.  It would be terrible
to have a botched release.  (Frankly, I’m a little uncomfortable about
such a big change right before the release, but maybe I’m just being
nervous about doing the release myself this time…)

-- 
Ricardo
  
  GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
  http://elephly.net

Re: Emacs-Guix released outside from Guix

[Ludovic Courtès]

Hi Alex!

Alex Kost  skribis:

> Hello, I've been working on Emacs interface outside from the Guix repo
> for some time, I mean I'm not going to maintain it inside Guix, sorry :-(
>
> The main reason, is, well, inconvenience for me: I don't like to bother
> people with patches, etc.  I tried to explain it at
> .

As someone who’s always trusted you to do the right thing, I’m of course
disappointed that we Guix folks didn’t get notified nor consulted before
the fact.  I would also have loved a reply to my message back then¹.
That’s your choice though.

¹ https://lists.gnu.org/archive/html/guix-devel/2016-07/msg01110.html

> There are 2 more reasons above that:
>
> - I'd like to make it available on MELPA (people asked about it several
>   times in the past);

This is surprising: I’d expect Guix users to install it with Guix, and
non-Guix users to, well, not care about Guix.

> - Currently, to be able to use it on non-GuixSD system, a user has to
>   install 'guix' package into their profile.  This has never looked good
>   to me (installing a whole guix only for a small part of it). I would
>   prefer to make "guix package -i emacs-guix" possible instead.

OK.

This change will prevent joint feature development (updating
completions, ‘emacs-build-system’ and how it interacts with the Emacs
UI, M-x guix, cross-cutting changes to the UI, and so on).  This isn’t
good news for users.

Breakage will occasionally occur as the Guix APIs change, which will
make us all a bit sad.  What are your thoughts?

> So I'd like to add 'emacs-guix' package (the current patchset) and to
> remove it from the Guix source tree, if you don't mind.

I think “if you don’t mind” is misplaced.

> The code of Emacs-Guix can be found on github¹ or notabug².  I've just
> made a release (v0.2); and I'm going to send a message with the summary
> of changes later.
>
> ¹ https://github.com/alezost/guix.el
> ² https://notabug.org/alezost/emacs-guix
>
> I'm also sending the following patches:
>
> [PATCH 1/2] gnu: Add emacs-bui.
> [PATCH 2/2] gnu: Add emacs-guix.

OK!

I’ll let you take care of the actual removal, along with update to the
Texinfo cross-references and doc/htmlxref.cnf (assuming the manual will
be available on-line.)  I think it would help users to keep
cross-references between the two manuals.

We need to see what Ricardo thinks and whether or not this can be done
before 0.12, which is slated for sometime next week.

Keep up the great Emacs work.  Long live guix.el!

Ludo’.