plist-based package.el (was Re: cl-defstruct-based package.el, now with ert tests and no external tar!)

[Daniel Hackney]

Looking at Bug#13291 ("The package description buffer needs an URL
button"), I'm having a crisis of confidence in my plan to use
`cl-defstruct' to represent `package-desc' structures. The big problem
with `cl-defstruct' in this case is its lack of extensibility. We are
going to want to add additional slots to `package-desc' structures over
time, but doing so would require redefining `package-desc' each time.
`cl-defstruct' requires that structures be of the exact length given in
the definition of the structure; if, for example, `package-desc-name'
gets a vector with an unexpected length, it will signal an error:

    (error "package-desc-name accessing a non-package-desc")

This is desirable for structures which don't change, but we are going
to want all sorts of extra slots in `package-desc' structures.

As a result, I'm going to refactor my refactor: I'll make
`package-desc' structures into plists, so that future additions don't
break existing code. I don't think this should be that invasive; all
accesses to `package-desc' structures occur through `package-desc-*'
functions anyway, so not much will change from my current iteration.

What a time to change my mind; I had just finished all of the coding
changes.

Daniel Hackney <address@hidden> wrote:
> Dmitry Gutov <address@hidden> wrote:
>> Any news on this?
>
> I was finishing up on exams, so this had to be put on hold. I'm
> starting up on it again. I think it's close to a mergable state, so
> I'll finish up the NEWS entry and submit the patch for merging.
>
>> I've been holding off on Bug#13291 both because it would complicate
>> the rebase of this changeset, and also because I'd like to use the
>> test harness you have here.
>
> Sounds good. I'll try to get things on my end totally finished so
> development can resume on the new version.
>
>> Daniel Hackney <address@hidden> writes:
>>> I'll do a better job of explaining the whole patch. Should I include
>>> that in some sort of file in the repo or just on the mailing list?
>>> Would a detailed-ish explanation of the changes and rationale be
>>> appropriate for the ChangeLog or NEWS files?
>>
>> You can start with ChangeLog files. When writing a changelog entry,
>> one usually briefly describes and sometimes justifies the mechanical
>> transformations being performed on the code, and it helps other people
>> understand the changes.
>
> Since it is a complete refactoring, what should I say? Should I include
> a line for each new or changed function, or simply refer people to the
> NEWS file?
>
>> I see you've also already started on NEWS entries.
>
> How does it look so far? Any suggestions on how to improve it?
>
>>> About package-x.el, is the HTML and RSS updating functionality actually
>>> used? Currently, the only way to access the functionality is calling
>>> `package-maint-add-news-item' or the non-interactive
>>> `package-upload-buffer-internal' directly. GNU ELPA clearly doesn't use
>>> the version in package-x.el, as the HTML generated is not what
>>> package-x produces.
>>
>> Probably not. Melpa and Elpakit don't seem to be using it either.
>>
>>> Can I consider it unused and delete it? If not, I'll refactor it with
>>> the rest of the code.
>>
>> Personally, I'd delete them, but that's not my call. Maybe decorate them
>> with FIXMEs, leave them unfixed and see if anyone complains up until the
>> pretest?
>
> I did some porting and they should continue to work, although they don't
> do much of anything useful, just like before.
>
> One other change I made, which probably deserves some discussion, is
> that I created a folder "test/automated/data" which is intended to hold
> test-related data. I created a subfolder "package" (so it is
> "test/automated/data/package") which contains a test "archive-contents"
> file, as well as test elisp files. My hope is that such a directory
> could be useful for other tests which need example data.
>
> I also added a rule in the "Makefile.in" to skip byte-compilation of the
> files in "data".
>
> --
> Daniel Hackney



--
Daniel Hackney