all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tim Visher <tim.visher@gmail.com>
To: Perry Smith <pedzsan@gmail.com>
Cc: emacs <help-gnu-emacs@gnu.org>
Subject: Re: transition to package.el
Date: Tue, 27 Aug 2013 09:17:12 -0400	[thread overview]
Message-ID: <CAHa53uwJ_bpPU3pGWXvJN7sgVAqd8zNrg3=U4xzTCBjN2tKUPA@mail.gmail.com> (raw)
In-Reply-To: <E574F4B2-2860-4F03-A540-464FC288CBF4@gmail.com>

Hi Perry,

On Mon, Aug 26, 2013 at 1:30 PM, Perry Smith <pedzsan@gmail.com> wrote:
> I have emacs 24.3 on my Mac and AIX hosts.  One .el file I currently have uses "assoc" which is obsolete so I need to update that file.  I thought it might be good to start transitioning over to using packages.
>
> I currently have a big git repository for .emacs.d (that happens to be public on Github) that I pull from and push to so I can move to a new host quickly and I can keep all the various accounts on various hosts more or less synced up.  Many of the things in this repository are things I've downloaded... things which are now available as packages.
>
> Does anyone have any suggestions for making this transition?  I don't see any blog posts on the topic.

I haven't written a post but I'll say that if you're on Emacs 24 which
includes package.el then it's very easy to do.

See these bits from my own .emacs.d:

https://github.com/timvisher/.emacs.d/blob/master/init.el#L8-L12
https://github.com/timvisher/.emacs.d/blob/master/timvisher/timvisher_package.el

The basic strategy, in either direction, is to require package and
then have a list of package symbols that you dolist over calling
package-install. See the files for more details.

This is all you'll need to do to get a consistent set of packages
installed. But…

> One question is if you would suggest checking in the packages downloaded into the git repository or have git ignore them?  I can see arguments both ways.  I'm wondering what other have found to work for them.

If you choose to go with not checking the packages in you're going to
be subject to a couple of things:

1. If ELPA/Marmalade/MELPA is ever down (I actually experienced this
when attempting to help a buddy of mine install my .emacs.d), you
won't be able to use your config. package will simply fail to install
things but then if you haven't very carefully crafted the rest of your
.emacs.d you'll almost certainly blow up because packages that should
be there aren't.

2. If versions have changed then you will get updated versions. On
more than one occasion I've dropped my .emacs.d down and had it start
up only to find that there are bugs or features removed from more
recent versions of a package. Since (atm) package doesn't allow you to
specify a version (if I had more time I'd be trying to develop this
feature because we really need it!), you just get whatever is most
recent. That means that if you do specify both Marmalade and MELPA,
for instance, you always get the dev snapshot because it sorts higher.
There is a way to configure this away but I can't find it atm.

3. If you do choose to upgrade and find a subtle bug or
incompatibility you'll be up a creek because there's no easy way to
revert to your earlier config.

So in light of those things I would recommend always checking in all
the packages you install. The biggest annoyance is that you'll have to
see a bunch of cruft in your commit logs.

Hope that helps!

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail



      parent reply	other threads:[~2013-08-27 13:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-26 17:30 transition to package.el Perry Smith
2013-08-26 17:44 ` Drew Adams
2013-08-26 18:14   ` Perry Smith
2013-08-26 19:12     ` Tassilo Horn
2013-08-26 22:44       ` Perry Smith
2013-08-27  7:00         ` Tassilo Horn
2013-08-27 13:17 ` Tim Visher [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHa53uwJ_bpPU3pGWXvJN7sgVAqd8zNrg3=U4xzTCBjN2tKUPA@mail.gmail.com' \
    --to=tim.visher@gmail.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=pedzsan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.