Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Stefan Monnier]

>     Add license file with GPLv3

Why?  It just bloats the tarball with yet another copy of the file every
Emacs user already has.

Please make sure those redundant files aren't included in the tarballs
(with `:ignore` or `.elpaignore`).


        Stefan

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Why?  It just bloats the tarball with yet another copy of the file every
> Emacs user already has.

It seems like a good idea that the packages themselves have that file in
their repository, but I don't feel strongly about it either way.  I'm
happy to stop suggesting to add that if you prefer; it will save me five
minutes per package or so.

> Please make sure those redundant files aren't included in the tarballs
> (with `:ignore` or `.elpaignore`).

How about adding the files "LICENSE", "LICENSE.md" and "COPYING" to a
global ignore list instead?  (Those three being the variations I have
seen so far.)

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Stefan Kangas]

Stefan Kangas <stefan@marxist.se> writes:

> How about adding the files "LICENSE", "LICENSE.md" and "COPYING" to a
> global ignore list instead?  (Those three being the variations I have
> seen so far.)

IOW, how about something like this (untested)?  I think there are some
other files that we could always exclude as well, like ".dir-locals.el",
".github", "*-tests.el", and ".travis.yml".

diff --git a/elpa-admin.el b/elpa-admin.el
index b4ad318ef..37b3112dd 100644
--- a/elpa-admin.el
+++ b/elpa-admin.el
@@ -562,6 +562,10 @@ auxillary files unless TARBALL-ONLY is non-nil ."
                    "######## Build of package %s FAILED!!")
                  tarball)))))

+(defvar elpaa--make-tarball-global-ignore
+  '("COPYING" "LICENSE" "LICENSE.md")
+  "List of files that will not be included in the tarball.")
+
 (defun elpaa--make-one-tarball-1 ( tarball dir pkg-spec metadata
                                  &optional revision-function tarball-only)
   (elpaa--with-temp-files
@@ -572,7 +576,8 @@ auxillary files unless TARBALL-ONLY is non-nil ."
                (make-directory destdir)))
           (vers (nth 1 metadata))
           (elpaignore (expand-file-name ".elpaignore" dir))
-          (ignores (elpaa--spec-get pkg-spec :ignored-files))
+          (ignores (append (elpaa--spec-get pkg-spec :ignored-files)
+                           elpaa--make-tarball-global-ignore))
           (renames (elpaa--spec-get pkg-spec :renames))
           (ldir    (elpaa--spec-get pkg-spec :lisp-dir))
           (re (concat "\\`" (regexp-quote pkgname)

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Philip Kaludercic]

Stefan Kangas <stefan@marxist.se> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> How about adding the files "LICENSE", "LICENSE.md" and "COPYING" to a
>> global ignore list instead?  (Those three being the variations I have
>> seen so far.)
>
> IOW, how about something like this (untested)?  I think there are some
> other files that we could always exclude as well, like ".dir-locals.el",
> ".github", "*-tests.el", and ".travis.yml".

Not sure about .dir-locals.el (the developers might be using the special
kind of indentation set via .dir-locals.el), but next to these I'd also
suggest removing "Cask" and "Makefile".

And while we are at it, is there a reason not to add a MELPA-like
keyword to manually specify what files are part of a package?  Whenever
a single repository is used to maintain multiple packages (like Magit or
Embark) there is always a long list of :ignored-files that have to be
duplicated for every package.  Perhaps a more general version of
.elpaignore could be used to declare packages externally.

> diff --git a/elpa-admin.el b/elpa-admin.el
> index b4ad318ef..37b3112dd 100644
> --- a/elpa-admin.el
> +++ b/elpa-admin.el
> @@ -562,6 +562,10 @@ auxillary files unless TARBALL-ONLY is non-nil ."
>                     "######## Build of package %s FAILED!!")
>                   tarball)))))
>
> +(defvar elpaa--make-tarball-global-ignore
> +  '("COPYING" "LICENSE" "LICENSE.md")
> +  "List of files that will not be included in the tarball.")
> +
>  (defun elpaa--make-one-tarball-1 ( tarball dir pkg-spec metadata
>                                   &optional revision-function tarball-only)
>    (elpaa--with-temp-files
> @@ -572,7 +576,8 @@ auxillary files unless TARBALL-ONLY is non-nil ."
>                 (make-directory destdir)))
>            (vers (nth 1 metadata))
>            (elpaignore (expand-file-name ".elpaignore" dir))
> -          (ignores (elpaa--spec-get pkg-spec :ignored-files))
> +          (ignores (append (elpaa--spec-get pkg-spec :ignored-files)
> +                           elpaa--make-tarball-global-ignore))
>            (renames (elpaa--spec-get pkg-spec :renames))
>            (ldir    (elpaa--spec-get pkg-spec :lisp-dir))
>            (re (concat "\\`" (regexp-quote pkgname)
>
>

-- 
	Philip Kaludercic

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> And while we are at it, is there a reason not to add a MELPA-like
> keyword to manually specify what files are part of a package?  Whenever
> a single repository is used to maintain multiple packages (like Magit or
> Embark) there is always a long list of :ignored-files that have to be
> duplicated for every package.  Perhaps a more general version of
> .elpaignore could be used to declare packages externally.

Both of these ideas sounds good to me.

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Stefan Monnier]

> And while we are at it, is there a reason not to add a MELPA-like
> keyword to manually specify what files are part of a package?  Whenever
> a single repository is used to maintain multiple packages (like Magit or
> Embark) there is always a long list of :ignored-files that have to be
> duplicated for every package.  Perhaps a more general version of
> .elpaignore could be used to declare packages externally.

I'm not very much in favor:

- We currently don't support such packages well anyway.
  There are various more-or-less minor annoyances that could be fixed
  without too much effort, e.g. the various Magit-derived packages get
  redundantly auto-sync'd, and they result in duplicate worktrees
  (unless you manually replace them with symlinks, admittedly).

- It gets worse when you consider installation via Git (rather
  than via ELPA), in which case you get all the sub-packages in your
  `load-path` even if you only activate one of them; and it's not
  clear how to fix that.

This second point (to me) means that we want to discourage these kinds of
multi-packages that are bundled in a single branch.


        Stefan

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> This second point (to me) means that we want to discourage these kinds of
> multi-packages that are bundled in a single branch.

But how does making our own work more tedious discourage package authors
from doing that?

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Stefan Monnier]

Stefan Kangas [2022-01-03 03:41:11] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> This second point (to me) means that we want to discourage these kinds of
>> multi-packages that are bundled in a single branch.
> But how does making our own work more tedious discourage package authors
> from doing that?

By magical thinking.


        Stefan

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > And while we are at it, is there a reason not to add a MELPA-like
  > keyword to manually specify what files are part of a package?  Whenever
  > a single repository is used to maintain multiple packages (like Magit or
  > Embark) there is always a long list of :ignored-files that have to be
  > duplicated for every package.  Perhaps a more general version of
  > .elpaignore could be used to declare packages externally.

Would you please post a self-contained description of what you propose
we do?  One that doesn't assume any knowledge of MELPA?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > And while we are at it, is there a reason not to add a MELPA-like
>   > keyword to manually specify what files are part of a package?  Whenever
>   > a single repository is used to maintain multiple packages (like Magit or
>   > Embark) there is always a long list of :ignored-files that have to be
>   > duplicated for every package.  Perhaps a more general version of
>   > .elpaignore could be used to declare packages externally.
>
> Would you please post a self-contained description of what you propose
> we do?  One that doesn't assume any knowledge of MELPA?

Currently, each package specification may have the form

           ("foo"       :url "https://git.host/path/to/repo"
            :ignored-files ("Makefile" "baz.el"))

           ("baz"       :url "https://git.host/path/to/repo"
            :ignored-files ("Makefile" "foo.el"))

where I assume that the repository consists of the files foo.el, baz.el
and Makefile, and you would want to distribute two separate packages.
What I was thinking of was to add a keyword like :files to explicitly
list what files are added to a package:

           ("foo"       :url "https://git.host/path/to/repo"
            :files ("foo.el"))

           ("baz"       :url "https://git.host/path/to/repo"
            :files ("baz.el"))

-- 
	Philip Kaludercic

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Thanks for the explanation.

Would it make sense to ask the developers to record in their repo
which files belong to which package, in some way that is convenient
for them?  If the developers are willing to do that (or have already
done that), maybe we could arrange to follow what they specify; then
we would not need to have to specify anything manually about how to
split up the repo into its various packages.

If the method we recommend is simple, and convenient for them, I think
most of them will agree to do it.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Stefan Monnier]

> IOW, how about something like this (untested)?  I think there are some
> other files that we could always exclude as well, like ".dir-locals.el",
> ".github", "*-tests.el", and ".travis.yml".

`.dir-locals.el`, `.github`, and `.travis.yml` are usually very small,
so I don't see much benefit in skipping them (and for `.dir-locals.el`
I can see a clear harm since users might still look at (or even edit)
the installed files and the local vars might be useful).
Same for the Makefiles.

I think rather than "are they useful" the criteria should be "are they
harmful".  E.g. I objected to the addition of a copy of the GPLv3 text
because in those packages it takes more space than the rest of the
package, which I consider harmful.


        Stefan

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> `.dir-locals.el`, `.github`, and `.travis.yml` are usually very small,
> so I don't see much benefit in skipping them (and for `.dir-locals.el`
> I can see a clear harm since users might still look at (or even edit)
> the installed files and the local vars might be useful).
> Same for the Makefiles.
>
> I think rather than "are they useful" the criteria should be "are they
> harmful".  E.g. I objected to the addition of a copy of the GPLv3 text
> because in those packages it takes more space than the rest of the
> package, which I consider harmful.

I can see the  sense in including ".dir-locals.el" but e.g. ".github"
and ".travis.yml" only makes sense in relation to proprietary software,
so I think arguably they are harmful.

I think other than that, I have no objection to what you write but we
should probably document that criteria somewhere.

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Stefan Monnier]

>  ".github" and ".travis.yml" only makes sense in relation to
> proprietary software, so I think arguably they are harmful.

Fair enough.

> I think other than that, I have no objection to what you write but we
> should probably document that criteria somewhere.

Someone™ could document it Somewhere™, indeed.
Probably in the part of the README that discusses the `:ignored-files`.


        Stefan

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>  ".github" and ".travis.yml" only makes sense in relation to
>> proprietary software, so I think arguably they are harmful.
>
> Fair enough.

BTW, I don't think you commented on test files, or did I miss it?

I think we should skip test files for the same reason as for the license
file.

> Someone™ could document it Somewhere™, indeed.
> Probably in the part of the README that discusses the `:ignored-files`.

I happen to know that Someone™ is writing up a patch and will commit it
Somewhere™ later.

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Stefan Monnier]

Stefan Kangas [2022-01-03 23:04:15] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>  ".github" and ".travis.yml" only makes sense in relation to
>>> proprietary software, so I think arguably they are harmful.
>> Fair enough.
> BTW, I don't think you commented on test files, or did I miss it?
> I think we should skip test files for the same reason as for the license
> file.

I think, just as for the license file, it depends on the case.
If the tests are small enough, I see no need to skip them.


        Stefan

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Stefan Monnier]

> How about adding the files "LICENSE", "LICENSE.md" and "COPYING" to a
> global ignore list instead?  (Those three being the variations I have
> seen so far.)

I'd rather not, especially since some packages may be using some
other license, in which case we shouldn't just skip them.


        Stefan

Re: [nongnu] elpa/rainbow-delimiters a32b39bdfe: Add license file with GPLv3

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'd rather not, especially since some packages may be using some
> other license, in which case we shouldn't just skip them.

OK, makes sense.  I will add the license file to :ignored-files for the
packages where I sent pull requests.  (I won't go around closing the
ones that remain open, but I'll update the recipes.)

What do you think about ignoring globally some of the other files I
mentioned?  We already ignore e.g. ".git" and ".gitignore", so I would
say those would be analogous.  I could write up a patch.