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

[Daniel Hackney]

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