emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Integrating package.el


From: Ted Zlatanov
Subject: Re: Integrating package.el
Date: Mon, 01 Mar 2010 11:14:16 -0600
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.91 (gnu/linux)

On Mon, 1 Mar 2010 17:32:21 +0100 Jonas Bernoulli <address@hidden> wrote: 

JB> (I am rather confused by the mixture of quoting styles.)
>>>> Emacs could recognize the Version header and always track it internally
>>>> when it loads a library file, maybe with a (version . "1.2") in the
>>>> load-history.  That would help a lot, I think.

JB> Absolutely. However this information is missing from a lot of
JB> libraries. Also even if library contain version information it is
JB> still uncommon that libraries state what version of their
JB> dependencies are actually required.  Cedet contains something like
JB> this - has this portion of cedet been merged into 23.2?

We have to start somewhere.  Tracking dependencies is not possible until
versions are consistent so I think it's OK to use (version . nil) in the
load-history for the libraries that don't have a version header.

JB> If such an extended `require' form (or similar standardized
JB> information in the library header) are not adopted there is no way
JB> to automatically extract this information.

JB> This means that maintainers of package repositories have to figure
JB> it out manually or just leave this information out completely.  I am
JB> mirroring 2100 packages - I won't do it manually.

I think it's reasonable to also require unit and integration tests for
packages, at least for those that are considered "reliable" by the
packaging system, to accomplish these goals.  But these are long-term
goals and I think they merit a separate discussion on emacs-devel.  I'll
start the discussion with my (as usual) naive questions :)

SM> I personnally don't care about the behavior if the user tries to
SM> activate two different versions of the same package in a given session.

JB> If I remember correctly what he meant to say was that loading
JB> multiple versions is a user error. Having multiple versions
JB> installed is still an option as is choosing a particular version by
JB> the user (as opposed to the sysadmin) at runtime.

Does elm.el support that scheme as package.el does, distinguishing
between package installation (with a versioned install dir) and package
activation?

>> OK.  But I still think Emacs should record the version as I suggested
>> whenever it finds it in a .el/.elc file.  It would help resolve many
>> annoying user-level bugs by showing exactly what version of the library
>> was loaded, not implied from the directory but directly from the version
>> header.  Does that require lots of changes?

JB> I agree. But as explained above this still doesn't help the package
JB> manager to determine which version of a dependency is required.

Yes, in this context I only meant to say it would save time when
debugging user errors.

Ted





reply via email to

[Prev in Thread] Current Thread [Next in Thread]