Re: Are there an elisp package manager like apt-get or cpan?

Re: Are there an elisp package manager like apt-get or cpan?

[Þorne]

chylli wrote:
> Hi. Are there an emacs lisp package manager like apt-get in debian or
> cpan in perl ? When I want to install a package, I just run a command,
> then emacs will find proper package in proper web site and install
> it.

Funny, i was just thinking of writing one the other day.  I got to
thinking that it would really be trivial to write something using
ange-ftp or tramp or whatever.  Something like asdf-install for Emacs.

You could have a function like `esdf-load' that goes and looks up a
keyword in a known flat-file database on the net consisting of (KEYWORD
. location) pairs, then grab the source from the location and load it.
`esdf-find-file' could do the same but just open it in a buffer.  And
`esdf-install' could grab it, save it to `esdf-install-directory' and
add (load "foo") to your .emacs (or something a little better).

And it could be called recursively.  So developers who have packages
using more than one file could have a package definition file that is
what esdf-install would point to, and that file would just have calls
to esdf-install for all the files in the package, in whatever order was
desired.

But the thing is, it is so easy to do this already if you know the
location of the file that it is hardly necessary.  So the real problem
is finding someone who wants to keep a database online of such
information, or even wants to archive the packages themselves as actual
downloadable, loadable .el files, rather that links to text in html
files and Usenet postings and such.  There is the Emacs Lisp List, and
the emacswiki, but the the data tends not to be consistently in the
form of clean .el files.

For whateven all that may be worth...

th

Re: Are there an elisp package manager like apt-get or cpan?

[Þorne]

Gosh, I should probably add that in the google Usenet archives there is
something called install.el, and more importantly, there is ell.el,
which i forgot to mention because i have yet to get it to work.  But i
think it is meant to do exactly what you are asking about.  But i'm not
sure.  Google web search for the "Emacs Lisp List".

th

Re: Are there an elisp package manager like apt-get or cpan?

[chylli]

thanks for your help. I'm looking for ell now.

-- 

Thanks & Regards

Chylli

Re: Are there an elisp package manager like apt-get or cpan?

[Tim X]

"Þorne" <ego111@gmail.com> writes:

> chylli wrote:
>> Hi. Are there an emacs lisp package manager like apt-get in debian or
>> cpan in perl ? When I want to install a package, I just run a command,
>> then emacs will find proper package in proper web site and install
>> it.
>
> Funny, i was just thinking of writing one the other day.  I got to
> thinking that it would really be trivial to write something using
> ange-ftp or tramp or whatever.  Something like asdf-install for Emacs.
>
> You could have a function like `esdf-load' that goes and looks up a
> keyword in a known flat-file database on the net consisting of (KEYWORD
> . location) pairs, then grab the source from the location and load it.
> `esdf-find-file' could do the same but just open it in a buffer.  And
> `esdf-install' could grab it, save it to `esdf-install-directory' and
> add (load "foo") to your .emacs (or something a little better).
>
> And it could be called recursively.  So developers who have packages
> using more than one file could have a package definition file that is
> what esdf-install would point to, and that file would just have calls
> to esdf-install for all the files in the package, in whatever order was
> desired.
>
> But the thing is, it is so easy to do this already if you know the
> location of the file that it is hardly necessary.  So the real problem
> is finding someone who wants to keep a database online of such
> information, or even wants to archive the packages themselves as actual
> downloadable, loadable .el files, rather that links to text in html
> files and Usenet postings and such.  There is the Emacs Lisp List, and
> the emacswiki, but the the data tends not to be consistently in the
> form of clean .el files.
>

I think you hit th enail on the head - the real problem is that we
don't have a central, maintained and up-to-date repository of emacs
packages. There have been anumber of emacs lisp archives in the past,
but they all seem to last only as long as the person who initiated the
effort is prepared to maintain things. Once they move on to something
else, it all just dies. 

It would be nice if some body like GNU would setup and maintain a
single comprehensive elisp archive. 

For debian users, a lot can be achieved by taking on the
responsability for packaging and maintaining a deb version - then
apt-get will do what we need.

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Are there an elisp package manager like apt-get or cpan?

[chylli]

Tim X <timx@nospam.dev.null> writes:

> "Þorne" <ego111@gmail.com> writes:
>
>> chylli wrote:
>>> Hi. Are there an emacs lisp package manager like apt-get in debian or
>>> cpan in perl ? When I want to install a package, I just run a command,
>>> then emacs will find proper package in proper web site and install
>>> it.
>>
>> Funny, i was just thinking of writing one the other day.  I got to
>> thinking that it would really be trivial to write something using
>> ange-ftp or tramp or whatever.  Something like asdf-install for Emacs.
>>
>> You could have a function like `esdf-load' that goes and looks up a
>> keyword in a known flat-file database on the net consisting of (KEYWORD
>> . location) pairs, then grab the source from the location and load it.
>> `esdf-find-file' could do the same but just open it in a buffer.  And
>> `esdf-install' could grab it, save it to `esdf-install-directory' and
>> add (load "foo") to your .emacs (or something a little better).
>>
>> And it could be called recursively.  So developers who have packages
>> using more than one file could have a package definition file that is
>> what esdf-install would point to, and that file would just have calls
>> to esdf-install for all the files in the package, in whatever order was
>> desired.
>>
>> But the thing is, it is so easy to do this already if you know the
>> location of the file that it is hardly necessary.  So the real problem
>> is finding someone who wants to keep a database online of such
>> information, or even wants to archive the packages themselves as actual
>> downloadable, loadable .el files, rather that links to text in html
>> files and Usenet postings and such.  There is the Emacs Lisp List, and
>> the emacswiki, but the the data tends not to be consistently in the
>> form of clean .el files.
>>
>
> I think you hit th enail on the head - the real problem is that we
> don't have a central, maintained and up-to-date repository of emacs
> packages. There have been anumber of emacs lisp archives in the past,
> but they all seem to last only as long as the person who initiated the
> effort is prepared to maintain things. Once they move on to something
> else, it all just dies. 
>
> It would be nice if some body like GNU would setup and maintain a
> single comprehensive elisp archive. 
>
> For debian users, a lot can be achieved by taking on the
> responsability for packaging and maintaining a deb version - then
> apt-get will do what we need.


>
> Tim
>
> -- 
> tcross (at) rapttech dot com dot au

I'm using ubuntu now. There are lots of elisp pakcages in ubuntu
source. But some of them has incompetence dependence. For example, I'm
using emacs-snapshot package. When I want to install some elisp
packages, ubuntu will try to install xemacs or emacs21 because that
package depend on them but not no emacs-snapshot. Same thing will
happen if I use a emacs compiled by myself. So I think building a
central, amintained and up-to-date will make sense. 

But I'm not good at elisp :(. Hope some experts will do that.

-- 

Thanks & Regards

Chylli

Re: Are there an elisp package manager like apt-get or cpan?

[Tassilo Horn]

Tim X <timx@nospam.dev.null> writes:

Hi Tim,

> I think you hit th enail on the head - the real problem is that we
> don't have a central, maintained and up-to-date repository of emacs
> packages. There have been anumber of emacs lisp archives in the past,
> but they all seem to last only as long as the person who initiated the
> effort is prepared to maintain things. Once they move on to something
> else, it all just dies.

If there was such an repository and an asdf-install like tool for elisp
I'm sure developers would update their packages themselves.

> It would be nice if some body like GNU would setup and maintain a
> single comprehensive elisp archive.

I think a simple packages.el on emacswiki.org would suffice in the
beginning. Then developers could update their packages themselves
without having to register somewhere.

Bye,
Tassilo
-- 
A child of five could understand this! Fetch me a child of five!

Re: Are there an elisp package manager like apt-get or cpan?

[Tim X]

Tassilo Horn <heimdall@uni-koblenz.de> writes:

> Tim X <timx@nospam.dev.null> writes:
>
> Hi Tim,
>
>> I think you hit th enail on the head - the real problem is that we
>> don't have a central, maintained and up-to-date repository of emacs
>> packages. There have been anumber of emacs lisp archives in the past,
>> but they all seem to last only as long as the person who initiated the
>> effort is prepared to maintain things. Once they move on to something
>> else, it all just dies.
>
> If there was such an repository and an asdf-install like tool for elisp
> I'm sure developers would update their packages themselves.
>
>> It would be nice if some body like GNU would setup and maintain a
>> single comprehensive elisp archive.
>
> I think a simple packages.el on emacswiki.org would suffice in the
> beginning. Then developers could update their packages themselves
> without having to register somewhere.
>

Yes, an asdf like package installer would be good for emacs. It would
be possible then to have an on-line list of asdf supported emacs
packages on the emacs wiki and then we could just do asdf::install. 

Of course, there are the security issues with both a wiki and with any
program that will seek out a package and install it for you. PGP keys
and checksums would address some of the later issues - don't know
about making sure the list is safe/reliable. A wiki is probably a bad
choice, but we would need something that enables maintainers to easily
update things. 

then again, maybe we don't need something as powerful as asdf and an
existing system, such as darcs, could do the job.

Tim


-- 
tcross (at) rapttech dot com dot au

Re: Are there an elisp package manager like apt-get or cpan?

[ken]

Þorne wrote:
> chylli wrote:
>> Hi. Are there an emacs lisp package manager like apt-get in debian or
>> cpan in perl ? When I want to install a package, I just run a command,
>> then emacs will find proper package in proper web site and install
>> it.
> 
> Funny, i was just thinking of writing one the other day.  I got to
> thinking that it would really be trivial to write something using
> ange-ftp or tramp or whatever.  Something like asdf-install for Emacs.
> 
> ....

I'll give a pitch for RPM.  There's been many a time when I've wanted to
upgrade emacs or elisp, but know that if I do, forever after I'll no
longer be able to use RPM for upgrades and I'll have to always upgrade
emacs and elisp manually.  So forget about enterprise environments.

Standards aren't much use if there's a bazillion of them and they're all
incompatible with one another.  So why bother with an app that will see
limited use and, more than likely, will be replaced in a few years by
something far more practical?

My $0.02.

Re: Are there an elisp package manager like apt-get or cpan?

[Robert D. Crawford]

ken <gebser@speakeasy.net> writes:

> I'll give a pitch for RPM.  There's been many a time when I've wanted to
> upgrade emacs or elisp, but know that if I do, forever after I'll no
> longer be able to use RPM for upgrades and I'll have to always upgrade
> emacs and elisp manually.  So forget about enterprise environments.

Not all of us fall into those categories.  I use debian, so rpm is a bad
solution, in this case anyway.  I would also stay away from apt in this
case for the same reasons.  Also, I am not, nor would I imagine are most
users on this list, in an enterprise environment.  

Furthermore, unless you are living on the bleeding edge of emacs
development, it does not change that often.  It seems to me that most
people would be able to live with an emacs installation for several
years without the need to upgrade.

While we are dreaming here, why don't we come up with a way to do a
complete installation from this packaging system... emacs and all.  Make
it so that it can sniff out the type of distro one uses and make the
adjustments to the package database so that the system knows that there
is a version of emacs/gnus/add-on-mode etc. installed.

I have to say that if someone goes ahead with this, it should work like
apt in that not only does it get the package and install it, it also
grabs whatever dependencies are needed.

> Standards aren't much use if there's a bazillion of them and they're all
> incompatible with one another.  So why bother with an app that will see
> limited use and, more than likely, will be replaced in a few years by
> something far more practical?

Living by this logic, we would never get anything done as there is
always something newer and better coming along.

rdc

-- 
Robert D. Crawford                                      rdc1x@comcast.net

QOTD:
	I opened Pandora's box, let the cat out of the bag and put the
	ball in their court.
		-- Hon. J. Hacker (The Ministry of Administrative Affairs)

Re: Is there an elisp package manager?

[ken]

Robert D. Crawford wrote:
> ken <gebser@speakeasy.net> writes:
> 
>> I'll give a pitch for RPM.  There's been many a time when I've wanted to
>> upgrade emacs or elisp, but know that if I do, forever after I'll no
>> longer be able to use RPM for upgrades and I'll have to always upgrade
>> emacs and elisp manually.  So forget about enterprise environments.
> 
> Not all of us fall into those categories.  I use debian, so rpm is a bad
> solution, in this case anyway.  I would also stay away from apt in this
> case for the same reasons.  

It's true that not everyone falls into these categories.  In fact, I
don't think there's *any* category that *everyone* falls into.  That
shouldn't be a reason for not doing something, otherwise nothing would
ever get done.  It might be more fruitful to think in terms of that
well-worn aphorism, "the greatest good for the greatest number."




> Also, I am not, nor would I imagine are most
> users on this list, in an enterprise environment.  

Most of those who manage an enterprise environment pay for support from
the distro provider.  They don't need this list.  Moreover, it's often
the case that installing your own packages on an enterprise-provided
machine is not permitted.  So, yes, I'd guess you're probably correct on
this point.  But then are we talking about creating a package just for
the people on this list?  Don't think so.  Again, consider the greatest
good for the greatest number.

The distro provider sometimes develops its own RPMs, but I doubt that it
happens very often that they'll grab an emacs version from CVS and make
an RPM out of it, I imagine for purely practical reasons.  But if there
were an easier path from CVS to RPM, then they would.


> Furthermore, unless you are living on the bleeding edge of emacs
> development, it does not change that often.  It seems to me that most
> people would be able to live with an emacs installation for several
> years without the need to upgrade.

This must be a matter of personal assessment.  For reasons mentioned in
my previous post, I've resisted upgrading emacs three times in the past
year when not doing so adversely affected projects I was working on.  I
think I upgrade my entire OS more often than you (or whoever is meant by
"most people") upgrade your (their) emacs.  And I thought I was more
sluggish in upgrading than most people?!

Whatever the mean frequency of upgrade, the point of creating the app in
question is to make upgrading easier-- and "easier" should take into
account maintenance of the system as a whole.  Maybe it's necessary to
have been responsible for systems administration to relate to that.


> 
> While we are dreaming here, why don't we come up with a way to do a
> complete installation from this packaging system... emacs and all.  Make
> it so that it can sniff out the type of distro one uses and make the
> adjustments to the package database so that the system knows that there
> is a version of emacs/gnus/add-on-mode etc. installed.

I'm not dreaming at all.  Though you may have a different opinion, I
believe what I've proposed is quite reasonable.

And what you're talking about (dreaming of?) already exists in large
degree.  Suse has a package manager, a wrapper for RPM called YaST2 that
can perform both installs and upgrades, from CD or HD or from the net.
(This would be yet another reason for packaging emacs upgrades into RPMs.)


> 
> I have to say that if someone goes ahead with this, it should work like
> apt in that not only does it get the package and install it, it also
> grabs whatever dependencies are needed.

YaST2 does this.  It also works from the CLI or in a GUI.  It also
provides dynamic help text where options arise.  It also authenticates
packages prior to their installation, a definite requirement if security
is a concern at all.

(Suse also runs apt.)


> 
>> Standards aren't much use if there's a bazillion of them and they're all
>> incompatible with one another.  So why bother with an app that will see
>> limited use and, more than likely, will be replaced in a few years by
>> something far more practical?
> 
> Living by this logic, we would never get anything done as there is
> always something newer and better coming along.

Your statement reminds of one from Yogi Berra: "Nobody goes there
anymore.  It's too crowded."  :)

I guess to understand my statement, it's necessary to understand that
some innovations are better than others, that some are, quite literally,
"called for" because they are so practical and far-sighted, while other
innovations are more like short-term cludges and fade from use after a
short time.  IOW, not all innovations are equal.  Again, think "the
greatest good for the greatest number," where "number" can also mean
others coming along in the future.


> 
> rdc
>