[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: feature/package-vc has been merged
From: |
Philip Kaludercic |
Subject: |
Re: feature/package-vc has been merged |
Date: |
Wed, 09 Nov 2022 17:35:46 +0000 |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Without such a system the package could be without use in many cases.
>> Many is probably the word of contention here. If you take a look at
>> elpa.git:elpa-packages, you'll find only a few :make or :shell-command
>> directives, none of which are critical. nongnu.git:elpa-packages has
>> non at all.
>
> Indeed. We don't use `make` or `ninja` to compile the ELisp files,
> instead we impose a standardized way to compile them.
>
> [ And those packages which rely on special build procedures will often
> suffer from problems with the native compiler, which will lazily
> recompile the files to native code without paying attention to the
> special build requirements. ]
What might be interesting is providing support for running commands to
build additional software a package needs, e.g. when a package
distributed a C module. But this wouldn't just be a package-vc thing,
but a thing that would interest all packages.
>> One thing I worry about, but which has also been discussed
>> here are :renames.
>
> Indeed. Currently `elpa-admin.el` doesn't obey them when using "install
> from Git" (it does obey them when building the tarballs, of course) :-(
>
>> E.g. Vertico uses these to move extensions from a subdirectory to the
>> main directory for packaging. But moving the files would be
>> registered by the VCS, and could make committing changes more
>> difficult. Maybe we could create symbolic/hard links instead
>> of renaming?
>
> Moving is definitely out of the question, but symlinks and hardlinks are
> also problematic. We should probably document that `:renames` are not
> fully supported in all cases and should thus be avoided.
> I currently count 6 :renames, two for `extensions/` and 4 for `docs/`.
I agree, luckily there hasn't been much need for it up until now.
> AFAIK Those for docs are needed only because `package-install` handles
> `.info` files only in the root directory of packages, but that doesn't
> afflict `package-vc`, so we should be able to find a better solution.
>
> Those for `extensions/` can be handled by adding `extensions/` to
> the `load-path` in the `<pkg>-autoloads.el` generated by
> `package-vc-install`.
OK, but how would this generalise? Hard-coding something like "if
'extensions/' is renamed to the '', then add 'extensions/' to
`load-path'" doesn't sound desirable.
>
> Stefan
- Re: feature/package-vc has been merged, (continued)
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/09
- Re: feature/package-vc has been merged, Björn Bidar, 2022/11/09
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/09
- Re: feature/package-vc has been merged, Björn Bidar, 2022/11/10
- Re: feature/package-vc has been merged, Stefan Monnier, 2022/11/09
- Re: feature/package-vc has been merged, Stefan Monnier, 2022/11/09
- Re: feature/package-vc has been merged,
Philip Kaludercic <=
- Re: feature/package-vc has been merged, Stefan Monnier, 2022/11/09
Re: feature/package-vc has been merged, Rudolf Adamkovič, 2022/11/05
- Re: feature/package-vc has been merged, Rudolf Adamkovič, 2022/11/05
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/06
- Re: feature/package-vc has been merged, Rudolf Adamkovič, 2022/11/06
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/07
- Re: feature/package-vc has been merged, Rudolf Adamkovič, 2022/11/07
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/08
- Re: feature/package-vc has been merged, Rudolf Adamkovič, 2022/11/08
- Re: feature/package-vc has been merged, Philip Kaludercic, 2022/11/09