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

Using borg in existing config #12

Open
justbur opened this Issue Jul 27, 2017 · 7 comments

Comments

4 participants
@justbur

justbur commented Jul 27, 2017

Hi, I'm interested in trying our borg for my config, but it looks like it will be annoying to merge my config with the one in the emacs.g repo.

I'd ideally like to just replace my package.el code with some borg code. Maybe by adding a borg folder in .emacs.d with the right dependencies. Is there an easy way to do this? I see the manual is structured around cloning .emacs.g and working from there.

Thanks

@tarsius tarsius added the question label Jul 28, 2017

@tarsius

This comment has been minimized.

Show comment
Hide comment
@tarsius

tarsius Jul 28, 2017

Member

It's indeed easiest to get started with borg if you have already decided to declare .emacs.d bankruptcy anyway. That being said, it's not that hard to merge an Emacs.g branch into an existing configuration. It's also possible to use package.el and borg together and to gradually migrate to the latter or keep using both. But how that is done isn't properly documented at the moment.

I plan to make it easier to use borg for only some packages (i.e. the ones the user had to patch or maintains themselve). See #11.

I was asked about migrating on Reddit before. For now please see that discussion. But feel free to ask follow up questions here.

The essential part of the configuration is this:

(add-to-list 'load-path (expand-file-name "lib/borg" user-emacs-directory))
(require  'borg)
(borg-initialize)

When initially merging a branch from Emacs.g (likely master) or alternatively the bootstrap configuration, then you most likely won't get any conflicts except for init.el. You can discard "their" side and put the above into the existing init.el before completing the merge.

If you keep on using package.el, then call package-initialize before the above, to ensure that packages installed with borg take precedence over those installed with package.el. Also avoid putting other configuration before the above code.

Member

tarsius commented Jul 28, 2017

It's indeed easiest to get started with borg if you have already decided to declare .emacs.d bankruptcy anyway. That being said, it's not that hard to merge an Emacs.g branch into an existing configuration. It's also possible to use package.el and borg together and to gradually migrate to the latter or keep using both. But how that is done isn't properly documented at the moment.

I plan to make it easier to use borg for only some packages (i.e. the ones the user had to patch or maintains themselve). See #11.

I was asked about migrating on Reddit before. For now please see that discussion. But feel free to ask follow up questions here.

The essential part of the configuration is this:

(add-to-list 'load-path (expand-file-name "lib/borg" user-emacs-directory))
(require  'borg)
(borg-initialize)

When initially merging a branch from Emacs.g (likely master) or alternatively the bootstrap configuration, then you most likely won't get any conflicts except for init.el. You can discard "their" side and put the above into the existing init.el before completing the merge.

If you keep on using package.el, then call package-initialize before the above, to ensure that packages installed with borg take precedence over those installed with package.el. Also avoid putting other configuration before the above code.

@tarsius tarsius self-assigned this Jul 28, 2017

@justbur

This comment has been minimized.

Show comment
Hide comment
@justbur

justbur Jul 30, 2017

Thanks for the explanation(s). I was able to set it up in my config without changing too much, although the code is pretty clunky right now.

I'm not sure this is for me yet, because it seems labor intensive. I had a few comments/ideas FWIW:

  1. It's a little annoying to me that the packages are built in their respective repos. After assimilating an building a package the repo is almost surely dirty because of either the -autoloads.el file or the .elc files. I then went to automatically update the .gitignore files to ignore these, but conceptually I didn't like that I was adding commits to ignore something in my local build process.

My thought was: could it somehow work so that the build happens outside of the repos? This would have the advantage of keeping the submodules in sync with their upstream and more "pristine".

  1. It would also be nice to have a way to replicate melpa-stable-like behavior and have a command to automatically update to commits that have version-like tags.

In any case, thank you for this it's interesting and useful. I think it accomplishes the goal of allowing complete control over your packages in a reasonably convenient way.

justbur commented Jul 30, 2017

Thanks for the explanation(s). I was able to set it up in my config without changing too much, although the code is pretty clunky right now.

I'm not sure this is for me yet, because it seems labor intensive. I had a few comments/ideas FWIW:

  1. It's a little annoying to me that the packages are built in their respective repos. After assimilating an building a package the repo is almost surely dirty because of either the -autoloads.el file or the .elc files. I then went to automatically update the .gitignore files to ignore these, but conceptually I didn't like that I was adding commits to ignore something in my local build process.

My thought was: could it somehow work so that the build happens outside of the repos? This would have the advantage of keeping the submodules in sync with their upstream and more "pristine".

  1. It would also be nice to have a way to replicate melpa-stable-like behavior and have a command to automatically update to commits that have version-like tags.

In any case, thank you for this it's interesting and useful. I think it accomplishes the goal of allowing complete control over your packages in a reasonably convenient way.

@tarsius

This comment has been minimized.

Show comment
Hide comment
@tarsius

tarsius Jul 30, 2017

Member
  1. It's a little annoying to me that the packages are built in their respective repos. After assimilating an building a package the repo is almost surely dirty because of either the -autoloads.el file or the .elc files. I then went to automatically update the .gitignore files to ignore these, but conceptually I didn't like that I was adding commits to ignore something in my local build process.

A few other people have pointed that out before, so there clearly is a need for some documentation here. I didn't document this from the get go because it seems so obvious to me: ignore these files once, globally, and be done with it. Or maybe I will just teach make bootstrap to do that.

  1. It would also be nice to have a way to replicate melpa-stable-like behavior and have a command to automatically update to commits that have version-like tags.

That sounds useful and I will probably add it. Also some other related batch functionality, though some of that will probably be implemented in a generic fashion in magit.

Member

tarsius commented Jul 30, 2017

  1. It's a little annoying to me that the packages are built in their respective repos. After assimilating an building a package the repo is almost surely dirty because of either the -autoloads.el file or the .elc files. I then went to automatically update the .gitignore files to ignore these, but conceptually I didn't like that I was adding commits to ignore something in my local build process.

A few other people have pointed that out before, so there clearly is a need for some documentation here. I didn't document this from the get go because it seems so obvious to me: ignore these files once, globally, and be done with it. Or maybe I will just teach make bootstrap to do that.

  1. It would also be nice to have a way to replicate melpa-stable-like behavior and have a command to automatically update to commits that have version-like tags.

That sounds useful and I will probably add it. Also some other related batch functionality, though some of that will probably be implemented in a generic fashion in magit.

@tarsius

This comment has been minimized.

Show comment
Hide comment
@tarsius

tarsius Jul 30, 2017

Member

Oh and you will notice that refreshing the status buffer gets rather slow if there are many modules. I started working on that today and discovered some low-hanging fruit. So this should be much less of a problem in a few days.

Member

tarsius commented Jul 30, 2017

Oh and you will notice that refreshing the status buffer gets rather slow if there are many modules. I started working on that today and discovered some low-hanging fruit. So this should be much less of a problem in a few days.

@DamienCassou

This comment has been minimized.

Show comment
Hide comment
@DamienCassou

DamienCassou Jul 31, 2017

Contributor

@justbur: I added the following to ~/.config/git/gitignore:

*.elc
*-autoloads.el
*.info
dir
flycheck_*.el
*-pkg.el
Contributor

DamienCassou commented Jul 31, 2017

@justbur: I added the following to ~/.config/git/gitignore:

*.elc
*-autoloads.el
*.info
dir
flycheck_*.el
*-pkg.el
@justbur

This comment has been minimized.

Show comment
Hide comment
@justbur

justbur Jul 31, 2017

A few other people have pointed that out before, so there clearly is a need for some documentation here. I didn't document this from the get go because it seems so obvious to me: ignore these files once, globally, and be done with it. Or maybe I will just teach make bootstrap to do that.

Fair enough. Also, thanks @DamienCassou for the example. I find globally ignoring files a bit odd (bc then you don't necessarily agree with others what a tracked file is), but in this context it's harmless it seems.

That sounds useful and I will probably add it. Also some other related batch functionality, though some of that will probably be implemented in a generic fashion in magit.

Great, thanks.

justbur commented Jul 31, 2017

A few other people have pointed that out before, so there clearly is a need for some documentation here. I didn't document this from the get go because it seems so obvious to me: ignore these files once, globally, and be done with it. Or maybe I will just teach make bootstrap to do that.

Fair enough. Also, thanks @DamienCassou for the example. I find globally ignoring files a bit odd (bc then you don't necessarily agree with others what a tracked file is), but in this context it's harmless it seems.

That sounds useful and I will probably add it. Also some other related batch functionality, though some of that will probably be implemented in a generic fashion in magit.

Great, thanks.

@vkz

This comment has been minimized.

Show comment
Hide comment
@vkz

vkz Dec 21, 2017

Fair enough. Also, thanks @DamienCassou for the example. I find globally ignoring files a bit odd (bc then you don't necessarily agree with others what a tracked file is), but in this context it's harmless it seems.

I thought about globally ignoring those generated files, but then figured another way:

git config diff.ignoreSubmodules untracked 

See --ignore-submodules section in man git-status for details. I wonder if it ever comes back to bite me.

vkz commented Dec 21, 2017

Fair enough. Also, thanks @DamienCassou for the example. I find globally ignoring files a bit odd (bc then you don't necessarily agree with others what a tracked file is), but in this context it's harmless it seems.

I thought about globally ignoring those generated files, but then figured another way:

git config diff.ignoreSubmodules untracked 

See --ignore-submodules section in man git-status for details. I wonder if it ever comes back to bite me.

@tarsius tarsius removed their assignment Mar 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment