ugexe
zef silently ignores malformed dependency specifications
Context
https://360.zef.pm/ currently has:
{
"api": "",
"auth": "zef:guifa",
"authors": [
"Matthew Stephen STUCKWISCH <[email protected]>"
],
"build-depends": [],
"depends": [
"Timezones::ZoneInfo:auth:<zef:guifa>:ver<0.4.1+>"
],
"description": "A module enabling experimental timezone support to DateTime",
"dist": "DateTime::Timezones:ver<0.4.1>:auth<zef:guifa>",
"license": "Artistic-2.0",
"meta-version": "0",
"name": "DateTime::Timezones",
"path": "D/AT/DATETIME_TIMEZONES/4ee01e4a6e9e19f8530518e82e58a0962595f365.tar.gz",
"perl": "6.*",
"provides": {
"DateTime::Timezones": "lib/DateTime/Timezones.rakumod"
},
"raku": "6.*",
"resources": [],
"source-url": "git://github.com/alabamenhu/DateTimeTimezones.git",
"support": {
"source": "git://github.com/alabamenhu/DateTimeTimezones.git"
},
"tags": [
"timezones",
"olson",
"datetime",
"time",
"date"
],
"test-depends": [
"Test"
],
"version": "0.4.1"
}
Notice the depends which has an extra : after auth.
When running zef --debug info -v 'DateTime::Timezones:ver<0.4.1>:auth<zef:guifa>' that dependency is not listed:
- Info for: DateTime::Timezones:ver<0.4.1>:auth<zef:guifa>
- Identity: DateTime::Timezones:ver<0.4.1>:auth<zef:guifa>
- Recommended By: Zef::Repository::LocalCache
- Installed: No
Description: A module enabling experimental timezone support to DateTime
License: Artistic-2.0
Source-url: git://github.com/alabamenhu/DateTimeTimezones.git
Provides: 1 modules
--------------------------------------------------
Module |Path-Name
--------------------------------------------------
DateTime::Timezones|lib/DateTime/Timezones.rakumod
--------------------------------------------------
Support:
# source: git://github.com/alabamenhu/DateTimeTimezones.git
Depends: 1 items
----------------------
ID|Identity|Installed?
----------------------
1 |Test |✓
----------------------
I would have expected some kind of error hinting at the malformed dependency spec.
Related to: https://github.com/tony-o/raku-fez/issues/70
Your Environment
- raku -v Welcome to Rakudo™ v2022.03. Implementing the Raku® Programming Language v6.d. Built on MoarVM version 2022.03.
- zef list --installed
===> Found via /home/patrickb/.rakubrew/versions/moar-2022.03/share/perl6/site
App::Prove6:ver<0.0.12>:authcpan:LEONT
Auth::SASL:ver<0.1.1>
Base64::Native:ver<0.0.8>:authzef:dwarring
Base64:ver<0.0.2>:authgithub:ugexe
CBOR::Simple:ver<0.1.1>:authzef:japhb
Concurrent::Progress:ver<1.1>:auth<Jonathan Worthington [email protected]>
Cro::Core:ver<0.8.7>
Cro::HTTP::Test:ver<0.8.1>
Cro::HTTP:ver<0.8.5>
Cro::HTTP:ver<0.8.7>
Cro::OpenAPI::RoutesFromDefinition:ver<1.0.2>
Cro::OpenAPI::RoutesFromDefinition:ver<1.0.4>
Cro::TLS:ver<0.8.7>
Cro::WebApp:ver<0.8.5>
Crypt::Random:ver<0.4.1>:authgithub:skinkade
DBDish::ODBC:ver<0.0.8>:authgithub:salortiz
DBIish:ver<0.6.4>:authzef:raku-community-modules:api<1>
DateTime::Format:ver<0.1.4>:authzef:raku-community-modules:api<1.0>
DateTime::Parse:ver<0.9.1>
Digest::HMAC:ver<1.0.2>:authgithub:retupmoca
Digest:ver<0.18.4>:auth<Lucien Grondin>
Distribution::Builder::MakeFromJSON:ver<0.6>:authgithub:niner
ECMA262Regex:ver<1.1.2>
Email::MIME:ver<2.0.5>:authgithub:retupmoca
Email::Simple:ver<2.1.1>:authzef:raku-community-modules
File::Directory::Tree:auth
File::Find:ver<0.1.1> File::Temp:ver<0.0.8> File::Which:ver<1.0.2> Getopt::Long:ver<0.3.3> HTML::Escape:ver<0.0.1> HTTP::HPACK:ver<0.9.3> HTTP::Tiny:ver<0.1.8>:authzef:jjatria IO::Path::ChildSecure:ver<1.001011> IO::Socket::Async::SSL:ver<0.7.10>:auth Inline::Perl5:ver<0.59>:authgithub:niner JSON::Fast:ver<0.15> JSON::Fast:ver<0.17>:authcpan:TIMOTIMO JSON::JWT:ver<1.1.1>:authzef:raku-community-modules JSON::Pointer:ver<1.0> LWP::Simple:ver<0.108>:authzef:raku-community-modules LibraryCheck:ver<0.0.10>:authgithub:jonathanstowe:api<1.0> LibraryMake:ver<1.0.0>:authgithub:retupmoca Log::Timeline:ver<0.4> MIME::Base64:ver<1.2.3>:authzef:raku-community-modules MIME::QuotedPrint:ver<1.0.0>:authgithub:retupmoca NativeHelpers::Blob:ver<0.1.12>:authgithub:salortiz NativeLibs:ver<0.0.9>:authgithub:salortiz Net::SMTP::Client::Async:ver<0.0.1> OO::Monitors:ver<1.1.1> OpenAPI::Model:ver<1.0.4> OpenAPI::Schema::Validate:ver<1.0.7> OpenSSL:ver<0.1.30>:authgithub:sergot PathTools:ver<0.1.1>:authgithub:ugexe Readline:ver<0.1.6>:authcpan:fooist SSH::LibSSH:ver<0.9.1>:auth<Jonathan Worthington [email protected]> Shell::Command System::Query:ver<0.1.6>:authzef:tony-o TAP:ver<0.3.5> Test::Assertion:ver<0.0.5>:authzef:lizmat Test::Mock:ver<1.5> TinyFloats:ver<0.0.4>:authzef:japhb URI::Encode:ver<0.09>:authzef:raku-community-modules URI:ver<0.3.5> YAMLish:ver<0.0.6> if:ver<0.1.1>:authgithub:FROGGS zef:ver<0.13.7>:authgithub:ugexe:api<0> ===> Found via /home/patrickb/.rakubrew/versions/moar-2022.03/share/perl6/core CORE:ver<6.d>:auth
One issue here is this goes into the "zef should validate META6 data" which I've generally been opposed to, instead insisting META6 validation should be occurring at the authoring level using e.g. Test::META. Ecosystems should be validating regardless of if zef does, and if/when that is the case there is little reason for zef to do the same (other than local validation for authoring modules, but again zef is not an authoring tool).
One consideration is the following is (surprisingly) not considered invalid:
raku -e 'use Test:auth:<Bar>;'
===SORRY!=== Error while compiling -e
Could not find Test:<Bar> in:
so it could even be questionable if the dependency spec is invalid and argue instead that zef should have failed to find Timezone::ZoneInfo:<zef:guifa>:ver<0.4.1+> or some such (which I agree with due to typically choosing consistency with raku use statements as much as possible).
We could also consider that dependency specs could technically exist for e.g. Java modules, although that is mostly moot as I imagine the spirit of this issue is for validating those with an explicit or implicit :from<Raku>
Ecosystems should be validating regardless of if zef does
That's what the fez ticket is about: https://github.com/tony-o/raku-fez/issues/70
I guess I'm fine with closing this ticket if the fez eco can guarantee that it's data is sane.
One issue here is this goes into the "zef should validate META6 data" which I've generally been opposed to
I agree. Zef shouldn't need to validate. It's just that in this case the data did not only look invalid, but erroneous and I expected some kind of error, wondering how zef managed to accept that strange dep spec. It feels like there is some "swallow all exceptions" going on, it should have failed somewhere even without a validation step.
so it could even be questionable if the dependency spec is invalid and argue instead that zef should have failed to find
Timezone::ZoneInfo:<zef:guifa>:ver<0.4.1+>or some such
I agree.