lizmat / Method-Also

Method::Also - add "is also" trait to Methods
Artistic License 2.0
2 stars 2 forks source link

[Windows10]: Type check failed in binding to parameter '$repo-id'; expected Str but got CompUnit::Repository::Spec #5

Open AntonOks opened 5 months ago

AntonOks commented 5 months ago
λ zef install Method::Also
===> Searching for: Method::Also
===> Staging Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Staging [OK] for Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Testing: Method::Also:ver<0.0.8>:auth<zef:lizmat>
[Method::Also] ===SORRY!=== Error while compiling C:\Users\<user>\AppData\Local\Temp\.zef\1717571754.23108\3a049392fd66e814f71522a197a5389c52eda0
[Method::Also] 60.tar.gz\Method-Also-0.0.8/t\01-basic.t
[Method::Also] Type check failed in binding to parameter '$repo-id'; expected Str but got CompUnit::Repository::Spec
[Method::Also] (CompUnit::Repository...)
[Method::Also] at C:\Users\<user>\AppData\Local\Temp\.zef\1717571754.23108\3a049392fd66e814f71522a197a
[Method::Also] 5389c52eda060.tar.gz\Method-Also-0.0.8/t\01-basic.t:2
===> Testing [FAIL]: Method::Also:ver<0.0.8>:auth<zef:lizmat>
Aborting due to test failure: Method::Also:ver<0.0.8>:auth<zef:lizmat> (use --force-test to override)

It all started at https://github.com/libxml-raku/LibXML-raku/issues/113

lizmat commented 5 months ago

Could you check out the repo on Windows, and run raku run-tests there and post the output?

AntonOks commented 5 months ago

Could you check out the repo on Windows, and run raku run-tests there and post the output?

Hi @lizmat

Sure... here we go:

λ raku run-tests
Welcome to Rakudo™ Star v2024.05.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2024.05.
Running on mswin32 (10.0.19042.746).

Testing Method-Also
=== t\01-basic.t

ALL OK
lizmat commented 5 months ago

Ok, but we are sure that the install failure with zef is not a flapper?

AntonOks commented 5 months ago

Ok, but we are sure that the install failure with zef is not a flapper?

Well, define a flapper? :O

It still doesn't work out of the box.

PS C:\Temp\Git\Method-Also [main]
λ date
Wed Jun  5 15:54:15 W. Europe Daylight Time 2024

PS C:\Temp\Git\Method-Also [main]
λ zef install Method::Also
===> Searching for: Method::Also
===> Staging Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Staging [OK] for Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Testing: Method::Also:ver<0.0.8>:auth<zef:lizmat>
[Method::Also] ===SORRY!=== Error while compiling C:\Users\<user>\AppData\Local\Temp\.zef\1717595659.21756\3a049392fd66e814f71522a197a5389c52eda0
[Method::Also] 60.tar.gz\Method-Also-0.0.8/t\01-basic.t
[Method::Also] Type check failed in binding to parameter '$repo-id'; expected Str but got CompUnit::Repository::Spec
[Method::Also] (CompUnit::Repository...)
[Method::Also] at C:\Users\<user>\AppData\Local\Temp\.zef\1717595659.21756\3a049392fd66e814f71522a197a
[Method::Also] 5389c52eda060.tar.gz\Method-Also-0.0.8/t\01-basic.t:2
===> Testing [FAIL]: Method::Also:ver<0.0.8>:auth<zef:lizmat>
Aborting due to test failure: Method::Also:ver<0.0.8>:auth<zef:lizmat> (use --force-test to override)

PS C:\Temp\Git\Method-Also [main]
λ date
Wed Jun  5 15:54:34 W. Europe Daylight Time 2024

Installation is done if --force-test is used, as suggested.

lizmat commented 5 months ago

A flapper is of something works / fails some times but not all the time.

So, this is not a flapper :-(

AntonOks commented 5 months ago

A flapper is of something works / fails some times but not all the time.

So, this is not a flapper :-(

Same on Windows11 :|

Is the error message ype check failed in binding to parameter '$repo-id'; expected Str but got CompUnit::Repository::Spec something to look into?!

lizmat commented 5 months ago

I find the 60.tar.gz in:

60.tar.gz\Method-Also-0.0.8/t\01-basic.t

a bit puzzling. Any idea where that is from?

On 5 Jun 2024, at 15:59, Anton Oks @.***> wrote:

Ok, but we are sure that the install failure with zef is not a flapper? Well, define a flapper? :O It still doesn't work out of the box. PS C:\Temp\Git\Method-Also [main] λ date Wed Jun 5 15:54:15 W. Europe Daylight Time 2024

PS C:\Temp\Git\Method-Also [main] λ zef install Method::Also ===> Searching for: Method::Also ===> Staging Method::Also:ver<0.0.8>:auth ===> Staging [OK] for Method::Also:ver<0.0.8>:auth ===> Testing: Method::Also:ver<0.0.8>:auth [Method::Also] ===SORRY!=== Error while compiling C:\Users\\AppData\Local\Temp.zef\1717595659.21756\3a049392fd66e814f71522a197a5389c52eda0 [Method::Also] 60.tar.gz\Method-Also-0.0.8/t\01-basic.t [Method::Also] Type check failed in binding to parameter '$repo-id'; expected Str but got CompUnit::Repository::Spec [Method::Also] (CompUnit::Repository...) [Method::Also] at C:\Users\\AppData\Local\Temp.zef\1717595659.21756\3a049392fd66e814f71522a197a [Method::Also] 5389c52eda060.tar.gz\Method-Also-0.0.8/t\01-basic.t:2 ===> Testing [FAIL]: Method::Also:ver<0.0.8>:auth Aborting due to test failure: Method::Also:ver<0.0.8>:auth (use --force-test to override)

PS C:\Temp\Git\Method-Also [main] λ date Wed Jun 5 15:54:34 W. Europe Daylight Time 2024

Installation is done if --force-test is used, as suggested. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

AntonOks commented 5 months ago

@lizmat

Well, that's ZEF output magic... just a line break :)

PS C:\Temp\Git\Method-Also [main ≡]
λ ls C:\Users\<user>\AppData\Local\Temp\.zef\1717700059.17700\3a049392fd66e814f71522a197a5389c52eda060.tar.gz\

    Directory: C:\Users\<user>\AppData\Local\Temp\.zef\1717700059.17700\3a049392fd66e814f71522a197a5389c52eda060.tar.gz

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----          23/07/2022    10:02                Method-Also-0.0.8

PS C:\Temp\Git\Method-Also [main ≡]
λ ls C:\Users\<user>\AppData\Local\Temp\.zef\1717700059.17700\3a049392fd66e814f71522a197a5389c52eda060.tar.gz\Method-Also-0.0.8\

    Directory: C:\Users\<user>\AppData\Local\Temp\.zef\1717700059.17700\3a049392fd66e814f71522a197a5389c52eda060.tar.gz\Method-Also-0.0.8

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----          23/07/2022    10:02                lib
d----          23/07/2022    10:02                t
-a---          23/07/2022    10:02            920 Changes
-a---          23/07/2022    10:02            176 dist.ini
-a---          23/07/2022    10:02           8902 LICENSE
-a---          23/07/2022    10:02            484 META6.json
-a---          23/07/2022    10:02           1355 README.md
-a---          23/07/2022    10:02           1385 run-tests
lizmat commented 5 months ago

@ugexe Any idea what's going on here?

AntonOks commented 5 months ago

@lizmat @ugexe

found this and this... tested and confirm, it's the same here, say $env:RAKULIB :(

ugexe commented 5 months ago

One of the links you posted says a workaround was implemented in zef 7 months ago. Are you using a recent version? When I try to install Method::Also on Windows using the latest zef if installs fine.

say $env:RAKULIB

For this to be useful we would need to know what that value is. Otherwise I'm not sure what we should infer from it.

AntonOks commented 5 months ago

My $RAKULIB is in my (Windows) home and named .raku

PS C:\Temp\Git\Method-Also [main ≡]
λ echo $env:RAKULIB
C:\Users\<user>\.raku

My installed versions are usually always "very recent"... as I use the scoop package manager

PS C:\Temp\Git\Method-Also [main ≡]
λ raku -version
Welcome to RakudoÔäó Star v2024.05.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2024.05.

PS C:\Temp\Git\Method-Also [main ≡]
λ zef -version
0.22.0

If I change $RAKULIB to point to a newly created directory, the problem persists

PS C:\Temp\Git\Method-Also [main ≡]
λ  zef install Method::Also
===> Searching for: Method::Also
===> Staging Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Staging [OK] for Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Testing: Method::Also:ver<0.0.8>:auth<zef:lizmat>
[Method::Also] ===SORRY!=== Error while compiling C:\Users\<user>\AppData\Local\Temp\.zef\1717851799.19772\3a049392fd66e814f71522a197a5389c52ed
[Method::Also] a060.tar.gz\Method-Also-0.0.8/t\01-basic.t
[Method::Also] Type check failed in binding to parameter '$repo-id'; expected Str but got CompUnit::Repository::Spec
[Method::Also] (CompUnit::Repository...)
[Method::Also] at C:\Users\<user>\AppData\Local\Temp\.zef\1717851799.19772\3a049392fd66e814f71522a
[Method::Also] 197a5389c52eda060.tar.gz\Method-Also-0.0.8/t\01-basic.t:2
===> Testing [FAIL]: Method::Also:ver<0.0.8>:auth<zef:lizmat>
Aborting due to test failure: Method::Also:ver<0.0.8>:auth<zef:lizmat> (use --force-test to override)

PS C:\Temp\Git\Method-Also [main ≡]
λ md C:\Temp\Rakudo\RAKULIB

    Directory: C:\Temp\Rakudo

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----          08/06/2024    15:03                RAKULIB

PS C:\Temp\Git\Method-Also [main ≡]
λ $env:RAKULIB = "C:\Temp\Rakudo\RAKULIB\"

PS C:\Temp\Git\Method-Also [main ≡]
λ echo $env:RAKULIB
C:\Temp\Rakudo\RAKULIB\

PS C:\Temp\Git\Method-Also [main ≡]
λ  zef install Method::Also
===> Searching for: Method::Also
===> Staging Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Staging [OK] for Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Testing: Method::Also:ver<0.0.8>:auth<zef:lizmat>
[Method::Also] ===SORRY!=== Error while compiling C:\Users\<user>\AppData\Local\Temp\.zef\1717851879.4024\3a049392fd66e814f71522a197a5389c52eda
[Method::Also] 060.tar.gz\Method-Also-0.0.8/t\01-basic.t
[Method::Also] Type check failed in binding to parameter '$repo-id'; expected Str but got CompUnit::Repository::Spec
[Method::Also] (CompUnit::Repository...)
[Method::Also] at C:\Users\<user>\AppData\Local\Temp\.zef\1717851879.4024\3a049392fd66e814f71522a19
[Method::Also] 7a5389c52eda060.tar.gz\Method-Also-0.0.8/t\01-basic.t:2
===> Testing [FAIL]: Method::Also:ver<0.0.8>:auth<zef:lizmat>
Aborting due to test failure: Method::Also:ver<0.0.8>:auth<zef:lizmat> (use --force-test to override)

PS C:\Temp\Git\Method-Also [main ≡]
λ ls C:\Temp\Rakudo\RAKULIB

    Directory: C:\Temp\Rakudo\RAKULIB

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----          08/06/2024    15:04                .precomp

Not sure if zef --debug unveils something more helpful

PS C:\Temp\Git\Method-Also [main ≡]
λ  zef install --debug Method::Also
===> Searching for: Method::Also
===> Found: Method::Also:ver<0.0.8>:auth<zef:lizmat> [via Zef::Repository::Ecosystems<fez>]
===> Fetching: Method::Also
[Method::Also] Fetching https://360.zef.pm/M/ET/METHOD_ALSO/3a049392fd66e814f71522a197a5389c52eda060.tar.gz with plugin: Zef::Service::Shell::curl
===> Fetching [OK]: Method::Also:ver<0.0.8>:auth<zef:lizmat> to C:\Users\<user>\AppData\Local\Temp/.zef/1717852406.4740\1717852408.4740.9780.746798020913\3a049392fd66e814f71522a197a5389c52eda060.tar.gz
===> Extracting: Method::Also
[Method::Also] Extracting with plugin: Zef::Service::Shell::tar
===> Extraction [OK]: Method::Also to C:\Users\<user>\AppData\Local\Temp/.zef/1717852406.4740\3a049392fd66e814f71522a197a5389c52eda060.tar.gz
===> Filtering: Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Filtering [OK] for Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> # SKIP: No need to build Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Staging Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Staging [OK] for Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Testing: Method::Also:ver<0.0.8>:auth<zef:lizmat>
[Method::Also] Testing with plugin: Zef::Service::TAP
[Method::Also] ===SORRY!=== Error while compiling C:\Users\<user>\AppData\Local\Temp\.zef\1717852406.4740\3a049392fd66e814f71522a197a5389c52eda
[Method::Also] 060.tar.gz\Method-Also-0.0.8/t\01-basic.t
[Method::Also] Type check failed in binding to parameter '$repo-id'; expected Str but got CompUnit::Repository::Spec
[Method::Also] (CompUnit::Repository...)
[Method::Also] at C:\Users\<user>\AppData\Local\Temp\.zef\1717852406.4740\3a049392fd66e814f71522a19
[Method::Also] 7a5389c52eda060.tar.gz\Method-Also-0.0.8/t\01-basic.t:2
[Method::Also] t\01-basic.t .. Dubious, test returned 1
[Method::Also] No subtests run
[Method::Also]
[Method::Also] Test Summary Report
[Method::Also] -------------------
[Method::Also] t\01-basic.t (Wstat: 256 Tests: 0 Failed: 0)
[Method::Also] Non-zero exit status: 1
[Method::Also]   Parse errors: No plan found in TAP output
[Method::Also] Files=1, Tests=0,  0 wallclock secs
[Method::Also] Result: FAILED
===> Testing [FAIL]: Method::Also:ver<0.0.8>:auth<zef:lizmat>
Aborting due to test failure: Method::Also:ver<0.0.8>:auth<zef:lizmat> (use --force-test to override)
ugexe commented 5 months ago

The debug output reveals it is using TAP::Harness. Does it work if you use --/tap-harness?

ugexe commented 5 months ago

I found another thing that suggests it might be related to TAP::Harness. Earlier I mentioned implementing a workaround for this in zef, which notably has this bit of code removed from zefs non TAP::Harness test plugin. If we then look at the source of TAP::Harness we can see it has code similar to what was removed in zef

ugexe commented 5 months ago

My $RAKULIB is in my (Windows) home and named .raku

You shouldn't have to do this as $HOME/.raku is in the repo chain by default

$ raku -e 'say $*REPO.repo-chain.head'
inst#/Users/nlogan/.raku
AntonOks commented 5 months ago

My $RAKULIB is in my (Windows) home and named .raku

You shouldn't have to do this as $HOME/.raku is in the repo chain by default

$ raku -e 'say $*REPO.repo-chain.head'
inst#/Users/nlogan/.raku

Thanks for the hint.

I keep the $RAKULIB env var as a reminder for another multiuser setup I have :O But thats a long story from my PERL5 days...

AntonOks commented 5 months ago

The debug output reveals it is using TAP::Harness. Does it work if you use --/tap-harness?

Well... yes and no :O ...

  1. No It seems like ZEF not only installs the module(s) into the $RAKULIB path but also (a copy) into directories, defined by the installed raku version?! Is this right? If so, the issue here is... my raku release is installed in ProgrammData, which is not writable for my user account. So, the "copy" of the module fails
    PS C:\Temp\Git\Method-Also [main ≡]
    λ  zef install --debug --/tap-harness Method::Also
    ===> Searching for: Method::Also
    ===> Found: Method::Also:ver<0.0.8>:auth<zef:lizmat> [via Zef::Repository::Ecosystems<fez>]
    ===> Fetching: Method::Also
    [Method::Also] Fetching https://360.zef.pm/M/ET/METHOD_ALSO/3a049392fd66e814f71522a197a5389c52eda060.tar.gz with plugin: Zef::Service::Shell::curl
    ===> Fetching [OK]: Method::Also:ver<0.0.8>:auth<zef:lizmat> to C:\Users\<user>\AppData\Local\Temp/.zef/1717931465.14136\1717931468.14136.5316.188510648489\3a049392fd66e814f71522a197a5389c52eda060.tar.gz
    ===> Extracting: Method::Also
    [Method::Also] Extracting with plugin: Zef::Service::Shell::tar
    ===> Extraction [OK]: Method::Also to C:\Users\<user>\AppData\Local\Temp/.zef/1717931465.14136\3a049392fd66e814f71522a197a5389c52eda060.tar.gz
    ===> Filtering: Method::Also:ver<0.0.8>:auth<zef:lizmat>
    ===> Filtering [OK] for Method::Also:ver<0.0.8>:auth<zef:lizmat>
    ===> # SKIP: No need to build Method::Also:ver<0.0.8>:auth<zef:lizmat>
    ===> Staging Method::Also:ver<0.0.8>:auth<zef:lizmat>
    ===> Staging [OK] for Method::Also:ver<0.0.8>:auth<zef:lizmat>
    ===> Testing: Method::Also:ver<0.0.8>:auth<zef:lizmat>
    [Method::Also] Testing with plugin: Zef::Service::Shell::Test
    [Method::Also] 1..11
    [Method::Also] ok 1 - the original foo
    [Method::Also] ok 2 - the first alias bar
    [Method::Also] ok 3 - the second alias bazzy
    [Method::Also] ok 4 - is foo() ok
    [Method::Also] ok 5 - is foo(666) ok
    [Method::Also] ok 6 - is bar() ok
    [Method::Also] ok 7 - is bazzy(768) ok
    [Method::Also] ok 8 - is Bar.bar_ber('a') ok
    [Method::Also] ok 9 - is Bar.bar_ber(42) ok
    [Method::Also] ok 10 - is Bar.bar_ber('a') ok
    [Method::Also] ok 11 - is Bar.bar_ber(42) ok
    ===> Testing [OK] for Method::Also:ver<0.0.8>:auth<zef:lizmat>
    ===> Installing staged code
    ===> Installing: Method::Also:ver<0.0.8>:auth<zef:lizmat>
    ===> Install [FAIL] for Method::Also:ver<0.0.8>:auth<zef:lizmat>: Failed to copy 'C:\Users\<user>\AppData\Local\Temp\.zef\1717931465.14136\1717931469.14136.3409.8178244742503\precomp\9783A8AFA22CDCB5096503AD5D8439588E40B127\B2\B2F7F7E46D6B516E58A9B1F15344F10C035CFCC2.lock' to 'C:\ProgramData\scoop\apps\rakudo-star\current\share\perl6\site\precomp\9783A8AFA22CDCB5096503AD5D8439588E40B127\B2\B2F7F7E46D6B516E58A9B1F15344F10C035CFCC2.lock': Failed to copy file: operation not permitted
    Failed to copy 'C:\Users\<user>\AppData\Local\Temp\.zef\1717931465.14136\1717931469.14136.3409.8178244742503\precomp\9783A8AFA22CDCB5096503AD5D8439588E40B127\B2\B2F7F7E46D6B516E58A9B1F15344F10C035CFCC2.lock' to 'C:\ProgramData\scoop\apps\rakudo-star\current\share\perl6\site\precomp\9783A8AFA22CDCB5096503AD5D8439588E40B127\B2\B2F7F7E46D6B516E58A9B1F15344F10C035CFCC2.lock': Failed to copy file: operation not permitted

If I install the module with "super powers" (as Admn), it works fine with the added --/tap-harness option...

PS C:\Temp\Git\Method-Also [main ≡]
λ sudo zef install --debug --/tap-harness Method::Also
===> Searching for: Method::Also
===> Found: Method::Also:ver<0.0.8>:auth<zef:lizmat> [via Zef::Repository::Ecosystems<fez>]
===> Fetching: Method::Also
[Method::Also] Fetching https://360.zef.pm/M/ET/METHOD_ALSO/3a049392fd66e814f71522a197a5389c52eda060.tar.gz with plugin: Zef::Service::Shell::curl
===> Fetching [OK]: Method::Also:ver<0.0.8>:auth<zef:lizmat> to C:\Users\<user>\AppData\Local\Temp/.zef/1717931569.15132\1717931570.15132.7235.336549536302\3a049392fd66e814f71522a197a5389c52eda060.tar.gz
===> Extracting: Method::Also
[Method::Also] Extracting with plugin: Zef::Service::Shell::tar
===> Extraction [OK]: Method::Also to C:\Users\<user>\AppData\Local\Temp/.zef/1717931569.15132\3a049392fd66e814f71522a197a5389c52eda060.tar.gz
===> Filtering: Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Filtering [OK] for Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> # SKIP: No need to build Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Staging Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Staging [OK] for Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Testing: Method::Also:ver<0.0.8>:auth<zef:lizmat>
[Method::Also] Testing with plugin: Zef::Service::Shell::Test
[Method::Also] 1..11
[Method::Also] ok 1 - the original foo
[Method::Also] ok 2 - the first alias bar
[Method::Also] ok 3 - the second alias bazzy
[Method::Also] ok 4 - is foo() ok
[Method::Also] ok 5 - is foo(666) ok
[Method::Also] ok 6 - is bar() ok
[Method::Also] ok 7 - is bazzy(768) ok
[Method::Also] ok 8 - is Bar.bar_ber('a') ok
[Method::Also] ok 9 - is Bar.bar_ber(42) ok
[Method::Also] ok 10 - is Bar.bar_ber('a') ok
[Method::Also] ok 11 - is Bar.bar_ber(42) ok
===> Testing [OK] for Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Installing staged code
===> Installing: Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Install [OK] for Method::Also:ver<0.0.8>:auth<zef:lizmat>
===> Installation [OK]

Whereas, even if the installation worked "ok", the module seems to be installed in the usual site directory instead (as I would expect it to be) in the configured $RAKULIB path

PS C:\Temp\Git\Method-Also [main ≡]
λ zef list --installed
===> Found via inst#C:\ProgramData\scoop\apps\rakudo-star\current\share\perl6\core
rakudo:ver<2024.05>:auth<Yet Another Society>
===> Found via inst#C:\ProgramData\scoop\apps\rakudo-star\current\share\perl6\site
App::Prove6:ver<0.0.17>:auth<cpan:LEONT>
App::Zef-Deps:ver<0.9.8>:auth<zef:coke>
Config::TOML:ver<0.1.2>:auth<atweiden>
Crane:ver<0.1.1>:auth<atweiden>
DBIish:ver<0.6.1>
DateTime::Format:ver<0.1.5>:auth<zef:raku-community-modules>:api<1.0>
DateTime::Parse:ver<0.9.3>:auth<github:sergot>
Digest:ver<1.1.0>:auth<zef:grondilu>
Encode:ver<0.0.4>:auth<github:sergot>
File::Directory::Tree:ver<0.1>:auth<zef:labster>
File::Find:ver<0.2.1>:auth<zef:raku-community-modules>
File::Temp:ver<0.0.11>:auth<zef:raku-community-modules>
File::Which:ver<1.0.4>
Getopt::Long:ver<0.4.2>
Grammar::Debugger:ver<1.0.1>:auth<github:jnthn>
Grammar::Profiler::Simple:ver<0.05>:auth<zef:raku-community-modules>
HTTP::Easy:ver<1.2>:auth<zef:raku-community-modules>
HTTP::Status:ver<0.0.4>:auth<zef:lizmat>
HTTP::UserAgent:ver<1.1.52>:auth<github:sergot>
IO::Capture::Simple:ver<v.0.0.2>:auth<zef:jjmerelo>
IO::Glob:ver<0.9.0>:auth<github:zostay>
IO::Socket::SSL:ver<0.0.3>:auth<github:sergot>
JSON::Class:ver<0.0.21>:auth<zef:jonathanstowe>:api<1.0>
JSON::Fast:ver<0.19>:auth<cpan:TIMOTIMO>
JSON::Marshal:ver<0.0.25>:auth<zef:jonathanstowe>:api<1.0>
JSON::Name:ver<0.0.7>:auth<zef:jonathanstowe>:api<1.0>
JSON::OptIn:ver<0.0.2>:auth<zef:jonathanstowe>
JSON::RPC:ver<1.0.6>:auth<zef:bbkr>
JSON::Tiny:ver<1.0>
JSON::Unmarshal:ver<0.15>:auth<zef:raku-community-modules>
L10N::DE:ver<0.0.1>:auth<zef:l10n>
L10N::EN:ver<0.0.1>:auth<zef:l10n>
L10N::FR:ver<0.0.1>:auth<zef:l10n>
L10N::HU:ver<0.0.1>:auth<zef:l10n>
L10N::IT:ver<0.0.1>:auth<zef:l10n>
L10N::NL:ver<0.0.1>:auth<zef:l10n>
L10N::PT:ver<0.0.1>:auth<zef:l10n>
L10N:ver<0.0.2>:auth<zef:l10n>
LWP::Simple:ver<0.109>:auth<zef:dwarring>
LibraryCheck:ver<0.0.12>:auth<zef:jonathanstowe>:api<1.0>
LibraryMake:ver<1.0.5>:auth<zef:jjmerelo>
License::SPDX:ver<3.24.0>:auth<zef:jonathanstowe>:api<1.0>
META6:ver<0.0.30>:auth<zef:jonathanstowe>:api<1.0>
MIME::Base64:ver<1.2.3>:auth<zef:raku-community-modules>
Method::Also:ver<0.0.8>:auth<zef:lizmat>
NativeHelpers::Blob:ver<0.1.12>:auth<github:salortiz>
OO::Monitors:ver<1.1.1>
OpenSSL:ver<0.2.2>:auth<github:sergot>
PSGI:ver<1.2.1>:auth<zef:raku-community-modules>
Path::Finder:ver<0.4.7>:auth<zef:leont>
PathTools:ver<0.2.0>:auth<github:ugexe>
Pod::Load:ver<0.7.2>:auth<zef:jjmerelo>
Pod::To::BigPage:ver<0.5.2>:auth<Perl 6>
Pod::Usage:ver<0.0.1>:auth<zef:leont>
Readline:ver<0.1.8>:auth<zef:clarkema>
SVG::Plot
SVG:ver<1.0>
Shell::Command:ver<1.1>:auth<zef:raku-community-modules>
Slang::Tuxic:ver<0.0.4>:auth<zef:raku-community-modules>
Slangify:ver<0.0.3>:auth<zef:lizmat>
TAP:ver<0.3.14>
Temp::Path:ver<1.001008>
Template6:ver<0.14.0>:auth<zef:raku-community-modules>
Template::Mojo:ver<0.2.2>:auth<zef:raku-community-modules>
Template::Mustache:ver<1.2.3>:auth<github:softmoth>
Terminal::ANSIColor:ver<0.10>:auth<zef:lizmat>
Terminal::ANSIParser:ver<0.0.3>:auth<zef:japhb>
Test::META:ver<0.0.20>:auth<zef:jonathanstowe>:api<1.0>
Test::Mock:ver<1.6>:auth<zef:jnthn>
Test::Output:ver<1.001006>:auth<zef:raku-community-modules>
Test::Util::ServerPort:ver<0.0.5>:auth<zef:jonathanstowe>:api<1.0>
Test::When:ver<1.001009>:auth<zef:raku-community-modules>
Testo:ver<1.003009>:auth<zef:raku-community-modules>
Text::CSV:ver<0.015>:auth<zef:Tux>
URI:ver<0.3.7>:auth<zef:raku-community-modules>
Win32::Registry:ver<0.0.7>:auth<zef:sdondley>
XML::Writer
XML:ver<0.3.3>:auth<zef:raku-community-modules>
YAMLish:ver<0.1.1>:auth<zef:leont>
sigpipe:ver<0.0.3>:auth<zef:leont>
zef:ver<0.22.0>:auth<github:ugexe>:api<0>
ugexe commented 5 months ago

I keep the $RAKULIB env var as a reminder for another multiuser setup I have :O But thats a long story from my PERL5 days...

If it isn't serving a functional purpose then I'd suggest not setting it, particularly to an existing repository path. Library path inclusion in Raku has very little in relation to Perl anymore, so one should not assume that emulating something they did in Perl is appropriate for Raku. For example you are effectively giving RAKULIB file#$HOME/.raku, but as I've shown earlier there is already a similar default inst#$HOME/.raku. You almost certainly wanted to use/install to the later, because we're working with installation repositories. Including two different types of repositories using the same path is likely to end in confusion at best.

It seems like ZEF not only installs the module(s) into the $RAKULIB path but also (a copy) into directories, defined by the installed raku version?! Is this right?

That isn't accurate. zef doesn't look at RAKULIB at all, including to figure out where to install distributions. You can read about how zef chooses where to install distributions here. For brevity the install location is chosen by first looking at --install-to=..., then by looking at ZEF_CONFIG_DEFAULTCUR=..., and finally by looking at resources/config.json#DefaultCUR. By default this is set to auto, which tells zef to pick the first writable default repository - see here.

If you are seeing directories (such as .precomp) showing up in $HOME/.raku it is because you have set RAKULIB= to a file (and not installation) repository path. This is being done by rakudo itself and has nothing to do with zef, which you can see for yourself by cding into an empty directory, running RAKULIB=. raku -e 'use Test; say 42', and then seeing there is now a .precomp directory. This result is one reason for not setting RAKULIB to an existing default repository path.

If so, the issue here is... my raku release is installed in ProgrammData, which is not writable for my user account. So, the "copy" of the module fails

Given what I just mentioned about zef choosing the first writable default repository, this does seem strange. I'm not sure if the error itself -- Failed to copy file: operation not permitted -- actually means a permissions issue (i.e. it is not a writable path) or if it is a different issue. It certainly seems like it is, but my mental model of how this all works does not align with that being the case. I would be interested in seeing the output for admin and normal users for:

$ raku -e 'say CompUnit::RepositoryRegistry.repository-for-name("site").can-install()'

$ raku -e 'say CompUnit::RepositoryRegistry.repository-for-name("home").can-install()'

With that being said, I think you should be able to force zef to install to the home repo by passing --install-to=home or setting ZEF_CONFIG_DEFAULTCUR=home

AntonOks commented 5 months ago

That isn't accurate. zef doesn't look at RAKULIB at all, including to figure out where to install distributions.

Well, from https://docs.raku.org/programs/03-environment-variables#Environment_variables_used_by_the_raku_command_line

RAKUDOLIB and RAKULIB append a comma-delimited list of paths to the search list for modules. RAKUDOLIB is evaluated first.

If a package manager, i.e. zef is then again ignoring the fact that raku first looks here, if this var is set, that somehow feels wrong. I would think, if this env var was set, it means also all new modules should be installed here per default. But, well, seems like thats not your / zef's opinion...

AntonOks commented 5 months ago
$ raku -e 'say CompUnit::RepositoryRegistry.repository-for-name("site").can-install()'

$ raku -e 'say CompUnit::RepositoryRegistry.repository-for-name("home").can-install()'

Admin:

PS C:\Temp\Git\scoop-aoks [master ≡ +1 ~1 -0 !]
λ sudo raku -e 'say CompUnit::RepositoryRegistry.repository-for-name("site").can-install()'
===SORRY!=== Error while compiling -e
Undeclared routine:
    site used at line 1

PS C:\Temp\Git\scoop-aoks [master ≡ +1 ~1 -0 !]
λ sudo 
===SORRY!=== Error while compiling -e
Undeclared routine:
    home used at line 1

User

PS C:\Temp\Git\scoop-aoks [master ≡ +1 ~1 -0 !]
λ raku -e 'say CompUnit::RepositoryRegistry.repository-for-name("site").can-install()'
True

PS C:\Temp\Git\scoop-aoks [master ≡ +1 ~1 -0 !]
λ raku -e 'say CompUnit::RepositoryRegistry.repository-for-name("home").can-install()'
True
AntonOks commented 5 months ago

I keep the $RAKULIB env var as a reminder for another multiuser setup I have :O But thats a long story from my PERL5 days...

If it isn't serving a functional purpose then I'd suggest not setting it, particularly to an existing repository path. Library path inclusion in Raku has very little in relation to Perl anymore, so one should not assume that emulating something they did in Perl is appropriate for Raku. For example you are effectively giving RAKULIB file#$HOME/.raku, but as I've shown earlier there is already a similar default inst#$HOME/.raku. You almost certainly wanted to use/install to the later, because we're working with installation repositories. Including two different types of repositories using the same path is likely to end in confusion at best.

It seems like ZEF not only installs the module(s) into the $RAKULIB path but also (a copy) into directories, defined by the installed raku version?! Is this right?

That isn't accurate. zef doesn't look at RAKULIB at all, including to figure out where to install distributions. You can read about how zef chooses where to install distributions here. For brevity the install location is chosen by first looking at --install-to=..., then by looking at ZEF_CONFIG_DEFAULTCUR=..., and finally by looking at resources/config.json#DefaultCUR. By default this is set to auto, which tells zef to pick the first writable default repository - see here.

If you are seeing directories (such as .precomp) showing up in $HOME/.raku it is because you have set RAKULIB= to a file (and not installation) repository path. This is being done by rakudo itself and has nothing to do with zef, which you can see for yourself by cding into an empty directory, running RAKULIB=. raku -e 'use Test; say 42', and then seeing there is now a .precomp directory. This result is one reason for not setting RAKULIB to an existing default repository path.

If so, the issue here is... my raku release is installed in ProgrammData, which is not writable for my user account. So, the "copy" of the module fails

Given what I just mentioned about zef choosing the first writable default repository, this does seem strange. I'm not sure if the error itself -- Failed to copy file: operation not permitted -- actually means a permissions issue (i.e. it is not a writable path) or if it is a different issue. It certainly seems like it is, but my mental model of how this all works does not align with that being the case. I would be interested in seeing the output for admin and normal users for:

$ raku -e 'say CompUnit::RepositoryRegistry.repository-for-name("site").can-install()'

$ raku -e 'say CompUnit::RepositoryRegistry.repository-for-name("home").can-install()'

With that being said, I think you should be able to force zef to install to the home repo by passing --install-to=home or setting ZEF_CONFIG_DEFAULTCUR=home

Thanks for all the details!!!! Nevertheless, I think we are now lost in all the zef specific and details somehow. At the end, it's still about, a package manager, say zef, fails to install a module once the $RAKULIB is set... which is a very official prominent raku variable... right?

ugexe commented 5 months ago

I have no idea what is going on with your admin example. Honestly it looks like a terminal and quote character issue.

The user example suggests that site is indeed writable. You can see the code rakudo uses to check if things can be installed: https://github.com/rakudo/rakudo/blob/d7425592ce85ed540165c45eea105cad9ed9c3b8/src/core.c/CompUnit/Repository/Installation.rakumod#L134-L136

At the end, it's still about, a package manager, say zef, fails to install a module once the $RAKULIB is set... which is a very official prominent raku variable... right?

The RAKULIB issue is that TAP::Harness also uses RAKULIB. It would have to be fixed in either TAP::Harness (easy enough for anyone - I linked the commit from zef that shows the required change) or in rakudo (difficult - or at least I have no direction to give anyone in how to fix this).

The Failed to copy file: operation not permitted issue also doesn't appear to be related to zef either. The examples I asked you to show me earlier are pure raku, and so is the code that copies files to the e.g. site repository path.

In other words all of the issues you are seeing could be reproduced without involving a package manager at all.

AntonOks commented 5 months ago

I found another thing that suggests it might be related to TAP::Harness. Earlier I mentioned implementing a workaround for this in zef, which notably has this bit of code removed from zefs non TAP::Harness test plugin. If we then look at the source of TAP::Harness we can see it has code similar to what was removed in zef

So, for your TAP::Harness related feedback, this would mean a roll-back of, https://github.com/Raku/tap-harness6/commit/20f9be912b6dd224f1f16d139fc1a3b98a2388b0 , right?

And, in consequence, your feedback means, the $RAKULIB env var has to be discontinued, right?

AntonOks commented 5 months ago

@lizmat @ugexe

Needless to say by now, I guess... anyhow, for the records... the same error happens also on Linux :|

So, again from my understanding... if this is not a zef related issue but more of a raku issue (?!), it either has to be fixed within raku or the environment variable $RAKULIB (and the like) need to be discontinued, right?

@lizmat Whats your take on that? And how to continue?

lizmat commented 5 months ago

I think I'm gonna transfer this issue to the rakudo repo

UPDATE: meh, does not appear to be possible :-(

AntonOks commented 5 months ago

I think I'm gonna transfer this issue to the rakudo repo

UPDATE: meh, does not appear to be possible :-(

I can open a new issue and add as many infos as possible?!

ugexe commented 5 months ago

So, for your TAP::Harness related feedback, this would mean a roll-back of, https://github.com/Raku/tap-harness6/commit/20f9be912b6dd224f1f16d139fc1a3b98a2388b0 , right?

For the most part yeah I think reverting that commit would fix the issue seen when testing under TAP::Harness

or the environment variable $RAKULIB (and the like) need to be discontinued, right?

I wouldn't say that, no. It would be more accurate to say something like "don't modify $RAKULIB at runtime unless you really understand what you are doing", and it would be a very limited subset of raku code that would want to do that.

AntonOks commented 5 months ago

So, for your TAP::Harness related feedback, this would mean a roll-back of, Raku/tap-harness6@20f9be9 , right?

For the most part yeah I think reverting that commit would fix the issue seen when testing under TAP::Harness

@lizmat What's your take on this? And have you the superpowers to revert it, or?

or the environment variable $RAKULIB (and the like) need to be discontinued, right?

I wouldn't say that, no. It would be more accurate to say something like "don't modify $RAKULIB at runtime unless you really understand what you are doing", and it would be a very limited subset of raku code that would want to do that.

Ok, would be great if you share your "understanding"... and maybe even update the doc's after agreement from i.e. the "Raku core" team!?!

I hereby also share my viewpoint / need for this... Don't only have the single individual developers in mind, but also thinks about those, who use raku in a bigger context and/or complex, say "Enterprise IT", environments. In our case, we have different departments and teams, developing own modules... or use pre-checked /-validated public modules. There is no way, we will "install" those tested qualified released modules on the hundreds IT-managed systems locally! Still, we allow installing local modules in certain cases on some special grouped IT-systems / environments. And so we do not want to overlay-mount the local native raku directories, say "site" and friends. All those qualified and released modules are available in an official unique global "directory", say $RAKULIB, in our environment.