transition to package.el

transition to package.el

[Perry Smith]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

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.

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.

Thank you for your time,
Perry


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

RE: transition to package.el

[Drew Adams]

> One .el file I currently have uses "assoc" which is obsolete

Just to be sure:

When you say one of your files "uses `assoc'", do you mean it uses the
function `assoc' or it requires the library `assoc.el'?

AFAIK, function `assoc' is not obsolete.
But library `assoc.el' is obsolete.

Re: transition to package.el

[Perry Smith]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]


On Aug 26, 2013, at 12:44 PM, Drew Adams <drew.adams@oracle.com> wrote:

>> One .el file I currently have uses "assoc" which is obsolete
> 
> Just to be sure:
> 
> When you say one of your files "uses `assoc'", do you mean it uses the
> function `assoc' or it requires the library `assoc.el'?
> 
> AFAIK, function `assoc' is not obsolete.
> But library `assoc.el' is obsolete.

yasnippet.el (the version I have) does (require 'assoc)



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: transition to package.el

[Tassilo Horn]

Perry Smith <pedzsan@gmail.com> writes:

>> AFAIK, function `assoc' is not obsolete.
>> But library `assoc.el' is obsolete.
>
> yasnippet.el (the version I have) does (require 'assoc)

Then you are using an old version.  Neither the bleeding edge one in its
git repository nor the currently released version in ELPA require assoc
anymore.

Bye,
Tassilo

Re: transition to package.el

[Perry Smith]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]


On Aug 26, 2013, at 2:12 PM, Tassilo Horn <tsdh@gnu.org> wrote:

> Perry Smith <pedzsan@gmail.com> writes:
> 
>>> AFAIK, function `assoc' is not obsolete.
>>> But library `assoc.el' is obsolete.
>> 
>> yasnippet.el (the version I have) does (require 'assoc)
> 
> Then you are using an old version.  Neither the bleeding edge one in its
> git repository nor the currently released version in ELPA require assoc
> anymore.

Yes.  That wasn't my original question.  I want to change to using package.el
to help with issues like this.  My original email was asking if anyone had any
suggestions / advice about how to do this transition.

Perry


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: transition to package.el

[Tassilo Horn]

Perry Smith <pedzsan@gmail.com> writes:

>>>> AFAIK, function `assoc' is not obsolete.
>>>> But library `assoc.el' is obsolete.
>>> 
>>> yasnippet.el (the version I have) does (require 'assoc)
>> 
>> Then you are using an old version.  Neither the bleeding edge one in
>> its git repository nor the currently released version in ELPA require
>> assoc anymore.
>
> Yes.  That wasn't my original question.  I want to change to using
> package.el to help with issues like this.  My original email was
> asking if anyone had any suggestions / advice about how to do this
> transition.

Well, I don't think there's a "business migration strategie" for that,
and neither is it needed.  I'd just delete the old yasnippet from my
.emacs.d/, delete the relevant load-path adjustment from my .emacs (if
there is one), install yasnippet from ELPA, and restart emacs to check
if it still works.  If so, start over with the next package.

Bye,
Tassilo

Re: transition to package.el

[Tim Visher]

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