package-vc.el should not fetch all commits.

package-vc.el should not fetch all commits.

[amano.kenji]

package-vc-install fetches all commits for a VCS emacs package.

I just want the latest.

package-vc-upgrade and package-vc-upgrade-all should prune everything except the latest commit.

I don't want VCS packages to grow in size over time.

Re: package-vc.el should not fetch all commits.

[Philip Kaludercic]

"amano.kenji" <amano.kenji@proton.me> writes:

> package-vc-install fetches all commits for a VCS emacs package.
>
> I just want the latest.
>
> package-vc-upgrade and package-vc-upgrade-all should prune everything except the latest commit.
>
> I don't want VCS packages to grow in size over time.

That is not really what package-vc is about (the intention /is/ to have
the revision history available, so that you can contribute patches).
That being said, if you say you are only interested in packages from
Git, you can use this quick hack:

--8<---------------cut here---------------start------------->8---
(require 'package)
(require 'vc-git)
(defun package-install-once-from-vc (url name)
  (interactive
   (let* ((url (read-string "URL: "))
	  (name (file-name-base (directory-file-name url))))
     (list url (read-string "Name: " name))))
  (let* ((tmp (make-temp-file "package" t))
	 (dir (expand-file-name name tmp)))
    (make-directory dir)
    (unless (vc-git--out-ok "clone" "--depth" "1" url dir)
      (error "Failed to install %s from %s" name url))
    (let ((desc (package-install-file dir)))
      (message "Package `%s' installed at version %s"
	       (package-desc-name desc)
	       (package-version-join
		(package-desc-version desc)))
      desc)))
--8<---------------cut here---------------end--------------->8---

This is still missing some of the conveniences of package-vc, such as
building manuals, resolving dependencies, etc. but you could integrate
`package-vc--unpack-1' into the mix to get that to work as well.  As is
the case with vc-packages in general, updating is difficult.

-- 
	Philip Kaludercic on peregrine

Re: package-vc.el should not fetch all commits.

[amano.kenji]

I can contribute patches even if I have only one specific commit or the latest commit.

That's a bad UX. package-vc.el is the only built-in way to install VCS packages, and there should be a built-in way to install only one commit and update to only one commit.

Gentoo linux achieved one-commit update and one-commit installation for its own package repositories because people did not want repositories to grow in size over time.

On Friday, March 1st, 2024 at 1:33 PM, Philip Kaludercic <philipk@posteo.net> wrote:

> "amano.kenji" amano.kenji@proton.me writes:
> 
> > package-vc-install fetches all commits for a VCS emacs package.
> > 
> > I just want the latest.
> > 
> > package-vc-upgrade and package-vc-upgrade-all should prune everything except the latest commit.
> > 
> > I don't want VCS packages to grow in size over time.
> 
> 
> That is not really what package-vc is about (the intention /is/ to have
> the revision history available, so that you can contribute patches).
> That being said, if you say you are only interested in packages from
> Git, you can use this quick hack:
> 
> --8<---------------cut here---------------start------------->8---
> 
> (require 'package)
> (require 'vc-git)
> (defun package-install-once-from-vc (url name)
> (interactive
> (let* ((url (read-string "URL: "))
> (name (file-name-base (directory-file-name url))))
> (list url (read-string "Name: " name))))
> (let* ((tmp (make-temp-file "package" t))
> (dir (expand-file-name name tmp)))
> (make-directory dir)
> (unless (vc-git--out-ok "clone" "--depth" "1" url dir)
> (error "Failed to install %s from %s" name url))
> (let ((desc (package-install-file dir)))
> (message "Package `%s' installed at version %s"
> (package-desc-name desc)
> (package-version-join
> (package-desc-version desc)))
> desc)))
> --8<---------------cut here---------------end--------------->8---
> 
> 
> This is still missing some of the conveniences of package-vc, such as
> building manuals, resolving dependencies, etc. but you could integrate
> `package-vc--unpack-1' into the mix to get that to work as well. As is
> the case with vc-packages in general, updating is difficult.
> 
> --
> Philip Kaludercic on peregrine

Re: package-vc.el should not fetch all commits.

[Philip Kaludercic]

"amano.kenji" <amano.kenji@proton.me> writes:

> I can contribute patches even if I have only one specific commit or the latest commit.

True, my bad I didn't realise that for patches, Git won't have a problem
with that, even though it seems obvious in retrospect.

A different problem would seem to be updating, or at least a "git pull"
would download the entire repository.

> That's a bad UX. package-vc.el is the only built-in way to install VCS
> packages, and there should be a built-in way to install only one
> commit and update to only one commit.

I find these claims difficult, since as mentioned before, the intention
behind writing package-vc is not just to install a package from a VCS,
and judging it as such is misguided IMO.

But feel free to work on it, I am not opposed to patches that wouldn't
violate the fundamental intentions behind package-vc, but I suspect that
the end-result will be a more advanced version of the command I provided
below.

Also, if you intend to work on this more seriously, we should move the
conversation to the bug tracker or private correspondence for the time
being, where we can discuss details and ideas.

> Gentoo linux achieved one-commit update and one-commit installation
> for its own package repositories because people did not want
> repositories to grow in size over time.

I am not familiar with Gentoo or why they build from Source (my
impression has always been that this is partially motivated by a
performance concern, and the ability to compile optimised executable
for the current system?).

> On Friday, March 1st, 2024 at 1:33 PM, Philip Kaludercic <philipk@posteo.net> wrote:
>
>> "amano.kenji" amano.kenji@proton.me writes:
>> 
>> > package-vc-install fetches all commits for a VCS emacs package.
>> > 
>> > I just want the latest.
>> > 
>> > package-vc-upgrade and package-vc-upgrade-all should prune everything except the latest commit.
>> > 
>> > I don't want VCS packages to grow in size over time.
>> 
>> 
>> That is not really what package-vc is about (the intention /is/ to have
>> the revision history available, so that you can contribute patches).
>> That being said, if you say you are only interested in packages from
>> Git, you can use this quick hack:
>> 
>> --8<---------------cut here---------------start------------->8---
>> 
>> (require 'package)
>> (require 'vc-git)
>> (defun package-install-once-from-vc (url name)
>> (interactive
>> (let* ((url (read-string "URL: "))
>> (name (file-name-base (directory-file-name url))))
>> (list url (read-string "Name: " name))))
>> (let* ((tmp (make-temp-file "package" t))
>> (dir (expand-file-name name tmp)))
>> (make-directory dir)
>> (unless (vc-git--out-ok "clone" "--depth" "1" url dir)
>> (error "Failed to install %s from %s" name url))
>> (let ((desc (package-install-file dir)))
>> (message "Package `%s' installed at version %s"
>> (package-desc-name desc)
>> (package-version-join
>> (package-desc-version desc)))
>> desc)))
>> --8<---------------cut here---------------end--------------->8---
>> 
>> 
>> This is still missing some of the conveniences of package-vc, such as
>> building manuals, resolving dependencies, etc. but you could integrate
>> `package-vc--unpack-1' into the mix to get that to work as well. As is
>> the case with vc-packages in general, updating is difficult.
>> 
>> --
>> Philip Kaludercic on peregrine

-- 
	Philip Kaludercic on peregrine

Re: package-vc.el should not fetch all commits.

[amano.kenji]

I have developed a few small softwares. Unfortunately, I'm trying to graduate software development. I want to stick to software tinkering. I just want to write a few tiny scripts here and there, and I don't know much about emacs lisp.

I don't know the intention behind package-vc.el, but I think it should be flexible enough to keep commit depth at 1 during installation and updates. That's not difficult if you know some git commands. Gentoo linux keeps commit depth at 1 for all package repositories by default.

When people use package-vc.el, in many cases, they have to use it because the desired packages aren't available on emacs package repositories. janet-ts-mode is one example. I just want the latest commit from VCS packages that are not available on emacs package repositories.

If no one wants to make package-vc.el flexible enough to do that, I guess I will just stick to elpaca.

On Saturday, March 2nd, 2024 at 6:53 AM, Philip Kaludercic <philipk@posteo.net> wrote:

> "amano.kenji" amano.kenji@proton.me writes:
> 
> > I can contribute patches even if I have only one specific commit or the latest commit.
> 
> 
> True, my bad I didn't realise that for patches, Git won't have a problem
> with that, even though it seems obvious in retrospect.
> 
> A different problem would seem to be updating, or at least a "git pull"
> would download the entire repository.
> 
> > That's a bad UX. package-vc.el is the only built-in way to install VCS
> > packages, and there should be a built-in way to install only one
> > commit and update to only one commit.
> 
> 
> I find these claims difficult, since as mentioned before, the intention
> behind writing package-vc is not just to install a package from a VCS,
> and judging it as such is misguided IMO.
> 
> But feel free to work on it, I am not opposed to patches that wouldn't
> violate the fundamental intentions behind package-vc, but I suspect that
> the end-result will be a more advanced version of the command I provided
> below.
> 
> Also, if you intend to work on this more seriously, we should move the
> conversation to the bug tracker or private correspondence for the time
> being, where we can discuss details and ideas.
> 
> > Gentoo linux achieved one-commit update and one-commit installation
> > for its own package repositories because people did not want
> > repositories to grow in size over time.
> 
> 
> I am not familiar with Gentoo or why they build from Source (my
> impression has always been that this is partially motivated by a
> performance concern, and the ability to compile optimised executable
> for the current system?).
> 
> > On Friday, March 1st, 2024 at 1:33 PM, Philip Kaludercic philipk@posteo.net wrote:
> > 
> > > "amano.kenji" amano.kenji@proton.me writes:
> > > 
> > > > package-vc-install fetches all commits for a VCS emacs package.
> > > > 
> > > > I just want the latest.
> > > > 
> > > > package-vc-upgrade and package-vc-upgrade-all should prune everything except the latest commit.
> > > > 
> > > > I don't want VCS packages to grow in size over time.
> > > 
> > > That is not really what package-vc is about (the intention /is/ to have
> > > the revision history available, so that you can contribute patches).
> > > That being said, if you say you are only interested in packages from
> > > Git, you can use this quick hack:
> > > 
> > > --8<---------------cut here---------------start------------->8---
> > > 
> > > (require 'package)
> > > (require 'vc-git)
> > > (defun package-install-once-from-vc (url name)
> > > (interactive
> > > (let* ((url (read-string "URL: "))
> > > (name (file-name-base (directory-file-name url))))
> > > (list url (read-string "Name: " name))))
> > > (let* ((tmp (make-temp-file "package" t))
> > > (dir (expand-file-name name tmp)))
> > > (make-directory dir)
> > > (unless (vc-git--out-ok "clone" "--depth" "1" url dir)
> > > (error "Failed to install %s from %s" name url))
> > > (let ((desc (package-install-file dir)))
> > > (message "Package `%s' installed at version %s"
> > > (package-desc-name desc)
> > > (package-version-join
> > > (package-desc-version desc)))
> > > desc)))
> > > --8<---------------cut here---------------end--------------->8---
> > > 
> > > This is still missing some of the conveniences of package-vc, such as
> > > building manuals, resolving dependencies, etc. but you could integrate
> > > `package-vc--unpack-1' into the mix to get that to work as well. As is
> > > the case with vc-packages in general, updating is difficult.
> > > 
> > > --
> > > Philip Kaludercic on peregrine
> 
> 
> --
> Philip Kaludercic on peregrine

Re: package-vc.el should not fetch all commits.

[Stefan Monnier via Users list for the GNU Emacs text editor]

> When people use package-vc.el, in many cases, they have to use it
> because the desired packages aren't available on Emacs
> package repositories.

Maybe that's what they use it for, but that's definitely not what it was
designed to do :-)


        Stefan

Re: package-vc.el should not fetch all commits.

[amano.kenji]

You say there is an intention behind package-vc.el. Do you know the intention?

On Saturday, March 2nd, 2024 at 2:40 PM, Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> > When people use package-vc.el, in many cases, they have to use it
> > because the desired packages aren't available on Emacs
> > package repositories.
> 
> 
> Maybe that's what they use it for, but that's definitely not what it was
> designed to do :-)
> 
> 
> Stefan

Re: package-vc.el should not fetch all commits.

[Stefan Monnier]

> You say there is an intention behind package-vc.el. Do you know the intention?

Yes, it's to install a package in a way that lets you easily hack on it,
including keeping some local changes, fixing bugs, submitting them
upstream, merging with some other version of the package, try a new
branch, ..


        Stefan

Re: package-vc.el should not fetch all commits.

[Philip Kaludercic]

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

>> You say there is an intention behind package-vc.el. Do you know the intention?
>
> Yes, it's to install a package in a way that lets you easily hack on it,
> including keeping some local changes, fixing bugs, submitting them
> upstream, merging with some other version of the package, try a new
> branch, ..

Right, but there is no inherent problem in supporting other workflows,
as long as it is reasonably doable.  E.g. we could add a user option
that could influence the arguments passed to vc-git-clone, so that one
can inject a --depth=1 argument, and restructure some of the package-vc
functionality to make it reusable for other intents (e.g. better
isolating the "building" from the "installing"), so that other packages
can make use of the logic that prepares manuals or resolves
dependencies.  But that should probable be discussed in a bug report,
not here.

-- 
	Philip Kaludercic on peregrine

Re: package-vc.el should not fetch all commits.

[Stefan Monnier]

> Right, but there is no inherent problem in supporting other workflows,
> as long as it is reasonably doable.  E.g. we could add a user option
> that could influence the arguments passed to vc-git-clone, so that one
> can inject a --depth=1 argument, and restructure some of the package-vc
> functionality to make it reusable for other intents (e.g. better
> isolating the "building" from the "installing"), so that other packages
> can make use of the logic that prepares manuals or resolves
> dependencies.  But that should probable be discussed in a bug report,
> not here.

But when it comes to installing from arbitrary Git repositories, I think
a better path would be to provide commands that let `package.el` use
a local clone, so that users can `git clone` any which way they prefer,
and then just `M-x package-use-that-clone`.

It would provide total flexibility for the users without needing endless
options in our code to handle each and every possible detail.


        Stefan

Re: package-vc.el should not fetch all commits.

[amano.kenji]

I want emacs to update all (VCS) packages.

If package management is outsourced, I can't update all packages with one emacs command.

On Monday, March 4th, 2024 at 4:30 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > Right, but there is no inherent problem in supporting other workflows,
> > as long as it is reasonably doable. E.g. we could add a user option
> > that could influence the arguments passed to vc-git-clone, so that one
> > can inject a --depth=1 argument, and restructure some of the package-vc
> > functionality to make it reusable for other intents (e.g. better
> > isolating the "building" from the "installing"), so that other packages
> > can make use of the logic that prepares manuals or resolves
> > dependencies. But that should probable be discussed in a bug report,
> > not here.
> 
> 
> But when it comes to installing from arbitrary Git repositories, I think
> a better path would be to provide commands that let `package.el` use
> a local clone, so that users can `git clone` any which way they prefer,
> and then just `M-x package-use-that-clone`.
> 
> It would provide total flexibility for the users without needing endless
> options in our code to handle each and every possible detail.
> 
> 
> Stefan

Re: package-vc.el should not fetch all commits.

[Philip Kaludercic]

"amano.kenji" <amano.kenji@proton.me> writes:

> I want emacs to update all (VCS) packages.
>
> If package management is outsourced, I can't update all packages with one emacs command.

I don't think Stefan is arguing to "outsource" package management.  I'd
imagine the idea would be that if you have a any Git repository, you
could just clone it whatever way you want, then M-x
package-use-that-clone the directory and it would be installed and
managed by package.el, which should include the ability to update the
package.

What I am pondering, is if this should be part of package/package-vc, or
if it would be better to make adjustments so that these can be flexibly
extended, and then we could have a "package-git" package on ELPA that
could provide the general interface that Stefan mentioned, and while one
is at it, some auxiliary commands that would streamline common operations.

> On Monday, March 4th, 2024 at 4:30 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> > Right, but there is no inherent problem in supporting other workflows,
>> > as long as it is reasonably doable. E.g. we could add a user option
>> > that could influence the arguments passed to vc-git-clone, so that one
>> > can inject a --depth=1 argument, and restructure some of the package-vc
>> > functionality to make it reusable for other intents (e.g. better
>> > isolating the "building" from the "installing"), so that other packages
>> > can make use of the logic that prepares manuals or resolves
>> > dependencies. But that should probable be discussed in a bug report,
>> > not here.
>> 
>> 
>> But when it comes to installing from arbitrary Git repositories, I think
>> a better path would be to provide commands that let `package.el` use
>> a local clone, so that users can `git clone` any which way they prefer,
>> and then just `M-x package-use-that-clone`.
>> 
>> It would provide total flexibility for the users without needing endless
>> options in our code to handle each and every possible detail.
>> 
>> 
>> Stefan

-- 
	Philip Kaludercic on peregrine

Re: package-vc.el should not fetch all commits.

[Stefan Monnier via Users list for the GNU Emacs text editor]

> What I am pondering, is if this should be part of package/package-vc, or
> if it would be better to make adjustments so that these can be flexibly
> extended, and then we could have a "package-git" package on ELPA that
> could provide the general interface that Stefan mentioned, and while one
> is at it, some auxiliary commands that would streamline common operations.

Actually, now that I look at it, `package-use-that-clone` seems to
already exist under the name `package-vc-install-from-checkout`.


        Stefan