GNU bug report logs -
#38140
ELPA needs a standard mechanism for single-package compilation
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38140 in the body.
You can then email your comments to 38140 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38140
; Package
emacs
.
(Fri, 08 Nov 2019 23:27:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Raffael Stocker <r.stocker <at> mnet-mail.de>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 08 Nov 2019 23:27:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
To compile a single ELPA package for tests or during development, it is
currently necessary to clone/pull the whole elpa.git. This is wasteful
if only a single package is of interest. ELPA should have a standard
mechanism that allows (pulling/)compiling/testing etc. of single
packages. I request that such a mechanism be implemented.
Greetings,
Raffael
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38140
; Package
emacs
.
(Sat, 18 Jan 2020 10:46:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 38140 <at> debbugs.gnu.org (full text, mbox):
Raffael Stocker <r.stocker <at> mnet-mail.de> writes:
> To compile a single ELPA package for tests or during development, it is
> currently necessary to clone/pull the whole elpa.git. This is wasteful
> if only a single package is of interest. ELPA should have a standard
> mechanism that allows (pulling/)compiling/testing etc. of single
> packages. I request that such a mechanism be implemented.
I don't think we want to split up elpa.git into many small ones to
support this use case, since the other side of the coin is that it
would make the job harder for the ELPA maintainers.
If you really want this, you could try "git clone --filter", but I'm
not sure if the GNU repositories are configured to allow for that.
Note also that there is already the possibility in ELPA to use an
external repository. This is optional and only used when there is a
specific need though, IIUC.
Best regards,
Stefan Kangas
PS. The repository is only 174 MB on my disk, which IMO is not that
much in this day and age.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38140
; Package
emacs
.
(Sat, 18 Jan 2020 15:31:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 38140 <at> debbugs.gnu.org (full text, mbox):
(I cc'ed Stefan Monnier, as the bug report was on his request.)
Stefan Kangas writes:
> Raffael Stocker <r.stocker <at> mnet-mail.de> writes:
>
>> To compile a single ELPA package for tests or during development, it is
>> currently necessary to clone/pull the whole elpa.git. This is wasteful
>> if only a single package is of interest. ELPA should have a standard
>> mechanism that allows (pulling/)compiling/testing etc. of single
>> packages. I request that such a mechanism be implemented.
>
> I don't think we want to split up elpa.git into many small ones to
> support this use case, since the other side of the coin is that it
> would make the job harder for the ELPA maintainers.
I agree.
> If you really want this, you could try "git clone --filter", but I'm
> not sure if the GNU repositories are configured to allow for that.
This is not so much about the amount of data. The problem is that a
full "make" takes quite long (at least on my fairly slow machine) and
the output pertaining to the package of interest is easily overlooked.
I think it would be fine to do a "git clone" of the full repo but then a
"make <package>" or something to check compilation of just one package
in an otherwise clean worktree. AFAIK this is not possible with the
current setup.
The idea is to have an easy and standard way of checking that a package
builds correctly.
> Note also that there is already the possibility in ELPA to use an
> external repository. This is optional and only used when there is a
> specific need though, IIUC.
Yes, but does this solve the problem with making only one package?
Regards,
Raffael
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38140
; Package
emacs
.
(Sat, 18 Jan 2020 16:56:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 38140 <at> debbugs.gnu.org (full text, mbox):
Raffael Stocker <r.stocker <at> mnet-mail.de> writes:
> The idea is to have an easy and standard way of checking that a package
> builds correctly.
Thank you, that is indeed quite different from cloning the repository.
This feature request now makes much more sense. I agree that we
should be able to build and run tests for individual packages.
Best regards,
Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38140
; Package
emacs
.
(Sat, 28 Nov 2020 18:51:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 38140 <at> debbugs.gnu.org (full text, mbox):
I just pushed to elpa.git a change to `GNUmakefile` which shouild make
it so you can
make packages/<mypkg>
and it will only compile the ELisp files of <mypkg> (it also updates
the `<pkg>-pkg.el` and `<pkg>-autoloads.el` along the way, so it
also does the job needed for the package to be "ready to use" by
`package-activate`).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#38140
; Package
emacs
.
(Wed, 21 Apr 2021 22:29:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 38140 <at> debbugs.gnu.org (full text, mbox):
tags 38140 fixed
close 38140
thanks
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> I just pushed to elpa.git a change to `GNUmakefile` which shouild make
> it so you can
>
> make packages/<mypkg>
>
> and it will only compile the ELisp files of <mypkg> (it also updates
> the `<pkg>-pkg.el` and `<pkg>-autoloads.el` along the way, so it
> also does the job needed for the package to be "ready to use" by
> `package-activate`).
I'm therefore closing this bug report.
Added tag(s) fixed.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Wed, 21 Apr 2021 22:29:03 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
38140 <at> debbugs.gnu.org and Raffael Stocker <r.stocker <at> mnet-mail.de>
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Wed, 21 Apr 2021 22:29:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 20 May 2021 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 339 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.