PERL modules missing from C:\Program Files\Git\usr\share\perl5\core_perl
1,220 views
Skip to first unread message
Tim Cox
Apr 30, 2018, 5:57:30 PM4/30/18
to git-for-windows
Hi
We are using git 2.16.1 at my company. Some users have a fresh install, others would have updated from various different older versions. On some computers, there are .pm files missing under C:\Program Files\Git\usr\share\perl5\core_perl. For example, CPAN and Pod are present on some machines but not on others.
Has anyone seen this before?
Tim
Johannes Schindelin
May 1, 2018, 7:48:55 AM5/1/18
to Tim Cox, git-for-windows
Hi Tim,
C:\Program Files\Git is not writable by mere users. As such, CPAN is
pretty much useless there, and it only adds to the weight of the Git for
Windows installer.
Therefore, I would consider it a bug if we shipped Perl modules that are
not strictly necessary to run Git's commands.
Ciao,
Johannes
pretty much useless there, and it only adds to the weight of the Git for
Windows installer.
Therefore, I would consider it a bug if we shipped Perl modules that are
not strictly necessary to run Git's commands.
Ciao,
Johannes
Tim Cox
May 1, 2018, 8:02:13 AM5/1/18
to git-for-windows
Hi Johannes
So if the installer has write access it will install these modules? I ask this because on some PC installations they (these modules) are there. Why would one installation be different than the other in this respect? Can write permissions on C:\Program Files prevent some modules from installing and others not? I would expect from one machine to the next if the installer selects the exact same options they would get the exact same files installed.
We are trying to find a way to trim our current in-house toolset that uses ActiveState perl by using the perl that ships with GIT (on windows). We don't want 2 copies of perl installed if we can avoid it.
Thanks Johannes
Tim
Johannes Schindelin
May 2, 2018, 2:19:13 AM5/2/18
to Tim Cox, git-for-windows
Hi Tim,
On Tue, 1 May 2018, Tim Cox wrote:
> So if the installer has write access it will install these modules?
No, but that write access would be a prerequisite to make CPAN useful.
Without write access, users cannot do much with it (you cannot update the
CPAN module using itself, for example).
That means that we would have to ship it, and worse: you would dictate to
the Git for Windows maintainer that he has to maintain this piece, too,
despite the fact that it has preciously little to do with Git, for
preciously little benefit to users other than yourself.
> I ask this because on some PC installations they (these modules) are
> there.
Probably by mistake, given my earlier explanation?
> Why would one installation be different than the other in this respect?
Because bugs happen?
> Can write permissions on C:\Program Files prevent some modules from
> installing and others not? I would expect from one machine to the next
> if the installer selects the exact same options they would get the exact
> same files installed.
Write permissions on C:\Program Files prevent all modules from installing
stuff. The point of CPAN is pretty much exclusively to install stuff.
Oh, and CPAN also has a dependency on the entire GCC toolchain because
some modules you may want to install must build native code.
So essentially, you are asking not for fries as a side, but for a Porsche
911.
> We are trying to find a way to trim our current in-house toolset that
> uses ActiveState perl by using the perl that ships with GIT (on
> windows). We don't want 2 copies of perl installed if we can avoid it.
Sure. Trimming your toolset makes sense.
In this case, it may be unavoidable to have two copies of Perl, as Perl is
not Perl is not Perl when every single Perl comes with a different set of
modules. In Git for Windows' case, we have to ship Perl with a certain set
of modules to support certain parts of Git that are implemented as Perl
scripts. That is literally the only reason Git ships with a copy of Perl,
and that is the only use case I am willing to maintain.
You could, of course, try to rip out Git for Windows' Perl and use your
ActiveState Perl instead. That should be possible (it used to be possible
at some stage, we have enough ActiveState-specific workaround to prove
that some contributors found that worthwhile). It would be your
responsibility to make that work, and to keep it working, of course.
Ciao,
Johannes
On Tue, 1 May 2018, Tim Cox wrote:
> So if the installer has write access it will install these modules?
Without write access, users cannot do much with it (you cannot update the
CPAN module using itself, for example).
That means that we would have to ship it, and worse: you would dictate to
the Git for Windows maintainer that he has to maintain this piece, too,
despite the fact that it has preciously little to do with Git, for
preciously little benefit to users other than yourself.
> I ask this because on some PC installations they (these modules) are
> there.
> Why would one installation be different than the other in this respect?
> Can write permissions on C:\Program Files prevent some modules from
> installing and others not? I would expect from one machine to the next
> if the installer selects the exact same options they would get the exact
> same files installed.
stuff. The point of CPAN is pretty much exclusively to install stuff.
Oh, and CPAN also has a dependency on the entire GCC toolchain because
some modules you may want to install must build native code.
So essentially, you are asking not for fries as a side, but for a Porsche
911.
> We are trying to find a way to trim our current in-house toolset that
> uses ActiveState perl by using the perl that ships with GIT (on
> windows). We don't want 2 copies of perl installed if we can avoid it.
In this case, it may be unavoidable to have two copies of Perl, as Perl is
not Perl is not Perl when every single Perl comes with a different set of
modules. In Git for Windows' case, we have to ship Perl with a certain set
of modules to support certain parts of Git that are implemented as Perl
scripts. That is literally the only reason Git ships with a copy of Perl,
and that is the only use case I am willing to maintain.
You could, of course, try to rip out Git for Windows' Perl and use your
ActiveState Perl instead. That should be possible (it used to be possible
at some stage, we have enough ActiveState-specific workaround to prove
that some contributors found that worthwhile). It would be your
responsibility to make that work, and to keep it working, of course.
Ciao,
Johannes
Gan Ainm
May 14, 2018, 6:30:51 PM5/14/18
to git-for-windows
On Tuesday, May 1, 2018 at 1:48:55 PM UTC+2, Johannes Schindelin wrote:
C:\Program Files\Git is not writable by mere users. As such, CPAN is
pretty much useless there, and it only adds to the weight of the Git for
Windows installer.
Therefore, I would consider it a bug if we shipped Perl modules that are
not strictly necessary to run Git's commands.
Ciao,
Johannes
Hi Johannes,
today I discovered that Perl POD is definitely broken in 2.17.0. Even calling perldoc, which is supplied with gfw 2.17.0, complains about not finding module POD::Usage which is a core module.
Cheers
Gan
Johannes Schindelin
May 15, 2018, 6:11:11 AM5/15/18
to Gan Ainm, git-for-windows
Hi Gan,
On Mon, 14 May 2018, Gan Ainm wrote:
> On Tuesday, May 1, 2018 at 1:48:55 PM UTC+2, Johannes Schindelin wrote:
>
> > C:\Program Files\Git is not writable by mere users. As such, CPAN is
> > pretty much useless there, and it only adds to the weight of the Git
> > for Windows installer.
> >
> > Therefore, I would consider it a bug if we shipped Perl modules that
> > are not strictly necessary to run Git's commands.
>
> not finding module *POD::Usage *which is a core module.
How is `perldoc` something that *Git* needs to do?
It is a bug to ship it in Git for Windows, but there is only so much one
maintainer can do when contributors only throw mails like this at him,
rather than PRs that fix things ;-)
Ciao,
Johannes
On Mon, 14 May 2018, Gan Ainm wrote:
> On Tuesday, May 1, 2018 at 1:48:55 PM UTC+2, Johannes Schindelin wrote:
>
> > C:\Program Files\Git is not writable by mere users. As such, CPAN is
> > pretty much useless there, and it only adds to the weight of the Git
> > for Windows installer.
> >
> > Therefore, I would consider it a bug if we shipped Perl modules that
> > are not strictly necessary to run Git's commands.
>
> today I discovered that Perl POD is definitely broken in 2.17.0. Even
> calling *perldoc*, which *is* supplied with gfw 2.17.0, complains about
> not finding module *POD::Usage *which is a core module.
How is `perldoc` something that *Git* needs to do?
It is a bug to ship it in Git for Windows, but there is only so much one
maintainer can do when contributors only throw mails like this at him,
rather than PRs that fix things ;-)
Ciao,
Johannes
Gan Ainm
May 18, 2018, 6:45:34 AM5/18/18
to Johannes Schindelin, git-for-windows
Hello Johannes,
On Tue, 15 May 2018 12:11:08 +0200 (DST)
Johannes Schindelin <Johannes....@gmx.de> wrote:
> > today I discovered that Perl POD is definitely broken in 2.17.0.
> > Even calling *perldoc*, which *is* supplied with gfw 2.17.0,
> > complains about not finding module *POD::Usage *which is a core
> > module.
>
> How is `perldoc` something that *Git* needs to do?
Of course, perldoc does not have a direct relationship to git.
However, as this tool is included in the git-bash package, many users
of git-bash use the tools within the package to implement toolchains
on Windows in order to have a single dependency only, i.e., git-bash.
I think there should be a clarification on the home page of
git-for-windows that explicitly states that git-bash is only a
self-contained support package to make Git available on Windows
machines and not a lightweight drop-in replacement for MSYS2 or
Cygwin.
> It is a bug to ship it in Git for Windows, but there is only so much
> one maintainer can do when contributors only throw mails like this at
> him, rather than PRs that fix things ;-)
If git-bash is meant to be a mere habitat for git on Windows, then
there is no need to file a PR, however, if its purpose is to support
unixoid toolchain development, I will happily create an issue.
Cheers
Gan
On Tue, 15 May 2018 12:11:08 +0200 (DST)
Johannes Schindelin <Johannes....@gmx.de> wrote:
> > today I discovered that Perl POD is definitely broken in 2.17.0.
> > Even calling *perldoc*, which *is* supplied with gfw 2.17.0,
> > complains about not finding module *POD::Usage *which is a core
> > module.
>
> How is `perldoc` something that *Git* needs to do?
However, as this tool is included in the git-bash package, many users
of git-bash use the tools within the package to implement toolchains
on Windows in order to have a single dependency only, i.e., git-bash.
I think there should be a clarification on the home page of
git-for-windows that explicitly states that git-bash is only a
self-contained support package to make Git available on Windows
machines and not a lightweight drop-in replacement for MSYS2 or
Cygwin.
> It is a bug to ship it in Git for Windows, but there is only so much
> one maintainer can do when contributors only throw mails like this at
> him, rather than PRs that fix things ;-)
there is no need to file a PR, however, if its purpose is to support
unixoid toolchain development, I will happily create an issue.
Cheers
Gan
Johannes Schindelin
May 18, 2018, 5:30:42 PM5/18/18
to Gan Ainm, git-for-windows
Hi Gan,
I really was talking about Pull Requests. If you open a ticket, you will
only increase the burden on me, personally. If that's what you want to do,
then go right ahead.
Ciao,
Johannes
only increase the burden on me, personally. If that's what you want to do,
then go right ahead.
Ciao,
Johannes
Mark Mikofski
May 18, 2018, 7:52:47 PM5/18/18
to git-for-windows
Hi Gan and Johannes,
Gan,
IMO your last statements are correct, and Johannes, please correct me if I am wrong.
Git-for-windows and the git-bash that ships with it are **not** meant to be a lightweight replacement for MSYS2 or Cygwin.
See this recent post "What's the difference between git-for-windows's git and msys2's git?"
I can submit a PR to update the homepage or wiki to reflect this if you think it is necessary? I can't guarantee that it will be merged, but I think it will lessen the burden the maintainers, such as Johannes, who are thankfully either volunteering their precious free time or may have only limited paid time to work on Git-for-Windows, so that they can work on more pressing issues.
The pages for Git-For-Windows repo is here: https://github.com/git-for-windows/git-for-windows.github.io
The page that it renders is here: https://gitforwindows.org/
the text is here:
Git for Windows focuses on offering a lightweight, native set of tools that bring the full feature set of the Git SCM to Windows while providing appropriate user interfaces for experienced Git users and novices alike.
Git BASH
Git for Windows provides a BASH emulation used to run Git from the command line. *NIX users should feel right at home, as the BASH emulation behaves just like the "git" command in LINUX and UNIX environments.
Is this the web page you are talking about? Or was it the main Git SCM site? Unfortunately I don't think that 2nd site (git-scm) is related to Git-For-Windows.
FYI: If you are on Windows 10, you might also consider using the Windows Subsystem for Linux which would be a heavyweight replacement for MSYS2
IMO I wouldn't consider adding either an issue or a PR to add perldoc functionality, because IMO Git-For-Windows only has one function, to bring Git to Windows using the Cygwin dll (aka msys2 dll)
Hope this helps!
mark
Reply all
Reply to author
Forward
0 new messages