🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
00:00 reportable6 left 00:01 reportable6 joined 00:05 Kaipei left
Geth rakudoc: opoku++ created pull request #17:
Use undeprecated Cache Store module		 00:15
SmokeMachine xinming: Thank you! Just added that. I've also added `multi method default-type-for-type(Blob --> Str:D) {"bytea"}` 00:22
Nemokosch For JSON::JWT I think I found the problem 00:45
grondilu's Digest module got a Digest::HMAC part... 00:46
which shadows the Digest::HMAC _module_
ugexe: do I understand it right that if you have a Digest::HMAC package lying around on your system, zef won't bother to look for a distribution under the same name? 01:05
01:05 linkable6 left, evalable6 left 01:06 linkable6 joined 01:08 evalable6 joined
leont Nemokosch: github.com/grondilu/libdigest-raku...6.json#L11 01:16
tellable6 leont, I'll pass your message to Nemokosch
leont tellable6-- 01:17
It's explicitly declaring it has a Digest::HMAC
Nemokosch yes, I know 01:54
for like a month
and that just broke at least one dependent of the actual Digest::HMAC distribution
but it could break any number of them 01:55
leont :auth<author> to the rescue?
Nemokosch well yes, one can fix Digest::HMAC itself with that, then JSON::JWT... but to go through each and every dependent of Digest::HMAC and check them one by one, now that doesn't sound fun, and especially not maintainable 02:00
and what does sound like could be (and should be, tbh) avoided, is that zef accepts random installed compunits as distributed modules 02:01
02:08 evalable6 left, linkable6 left
Like really, I think the naming part was alright, this shouldn't even render as a name collision on zef/dependency management level 02:08
02:09 linkable6 joined 02:10 evalable6 joined
There was a Digest distribution that had no (separate) hmac functionality for a long time. One was provided in a separate distribution by a different author, as a dependant of Digest. It got the name Digest::HMAC. I think so far so good. 02:10
Now, as time passes, the author of the Digest distribution decides to finally create a hmac functionality, logically under the module name Digest::HMAC, within the Digest distribution. This module happens to have a different API from the Digest::HMAC module that a lot of people had used by the time. 02:11
Nobody did anything "wrong" here. Compunit layouts just shouldn't pollute the namespace of distributions. 02:13
Dependencies should be distributions - or at least distributions *by default*. No compunit business 02:15
Isn't the name itself telling? "Distribution". That's the unit of publishing and sharing code. 02:16
02:42 simcop2387 left 02:44 simcop2387 joined
jaguart Is the conflict because: Distribution is a name for a set of provides => [CompUnits...], and Repository is a collection of Compunits 03:01
ie Distribution is more like a bundle than a namespace
and the dependency information in the META6 is at a CompUnit level 03:04
03:44 linkable6 left, evalable6 left 03:45 evalable6 joined 03:47 linkable6 joined 04:47 quotable6 left, squashable6 left, nativecallable6 left, coverable6 left, greppable6 left, statisfiable6 left, bloatable6 left, evalable6 left, releasable6 left, unicodable6 left, reportable6 left, shareable6 left, committable6 left, notable6 left, tellable6 left, sourceable6 left, bisectable6 left, benchable6 left, linkable6 left 04:48 bisectable6 joined, greppable6 joined, committable6 joined, bloatable6 joined 04:49 tellable6 joined, benchable6 joined, quotable6 joined, coverable6 joined, linkable6 joined, squashable6 joined, unicodable6 joined 04:50 reportable6 joined, releasable6 joined, shareable6 joined, sourceable6 joined, statisfiable6 joined, notable6 joined, nativecallable6 joined, evalable6 joined 05:10 sdfgsdfg joined 06:00 reportable6 left 06:03 reportable6 joined 07:03 statisfiable6 left, squashable6 left, evalable6 left, sourceable6 left, tellable6 left, coverable6 left, notable6 left, bisectable6 left, greppable6 left, shareable6 left, committable6 left, reportable6 left, benchable6 left, bloatable6 left, unicodable6 left, nativecallable6 left, linkable6 left, quotable6 left, releasable6 left, sourceable6 joined, linkable6 joined 07:04 squashable6 joined, committable6 joined, releasable6 joined, unicodable6 joined, tellable6 joined, bisectable6 joined, bloatable6 joined 07:05 quotable6 joined, benchable6 joined, shareable6 joined, coverable6 joined, statisfiable6 joined, evalable6 joined, reportable6 joined, nativecallable6 joined 07:06 notable6 joined, greppable6 joined 07:10 xinming left, xinming joined
nine Modules depend on other modules (or external things). They don't care which distribution a module is contained in. If you want a specific module, you just need to be a bit more specific. "I need to talk to John" is convenient and depending on context may be fully enough, but I wouldn't bet on it in a global context. 07:52
08:10 Kaipei joined 09:00 samebchase left 09:23 sena_kun left 09:24 sena_kun joined 09:57 grondilu joined
grondilu Apparently creating Mix objects is tricky whenever we want amounts not to be one. 09:58
If I understand correctly, to do it you have to use the .Mix coercer 09:59
The Mix.new constructor will treat pairs as keys 10:00
but what if I want to inherit from Mix?
m: say class :: is Mix {}.new("foo" => pi)<foo> 10:02
camelia 0
grondilu m: say class Foo is Mix {}; say ("foo" => pi).Foo;
camelia (Foo)
No such method 'Foo' for invocant of type 'Pair'
in block <unit> at <tmp> line 1
grondilu I could encapsulate a Mix object inside a Foo class but meh 10:04
or create a Foo role and compose it into to a Mix object but again... meh 10:05
10:11 grondilu left
grondilu Nevermind I realize and can use docs.raku.org/type/Mixy#(Baggy)_me...from-pairs 10:27
10:47 Sgeo left
Nemokosch META6 belongs to a distribution, not a module. It declares the dependencies of a distribution and it provides a set of modules. 11:04
One installs distributions with zef, not modules 11:06
Consequently, META6 dependencies are always external dependencies, not dependencies within the distribution. 11:09
11:11 jpn joined
And external dependencies make no sense to be modules on a high level. There is no ecosystem that stores and exposes individual modules, there is no high-level way to get a module from the ecosystem 11:12
I actually like jaguart's phrasing: a module is like a namespace. Now, tell me a language where you depend on namespaces rather than the bundle that may or may not expose them. 11:15
By the way: is there at least a way to tell zef "install this DISTRIBUTION, DON'T look up modules"? 11:27
nine That question is easy: Raku. But that's not the only one. Another answer would be Perl.
Nemokosch But like... did nobody wonder why noone else does this? 11:28
nine Moving goal posts, aren't we? 11:29
Nemokosch I mean... do you sincerely think that this was a legitimate answer?
"Oh, this very language does it." That's more like a bruh moment 11:30
nine Sticking with your example: when my module does `use Digest::HMAC`, all it needs is a Digest::HMAC module. That's my codes dependency. Therefore that's what we put into META6.json. I really don't care if that module is in its own distribution, a part of a Digest distribution, comes from zef, or e.g. my Linux distributions package manager. And I for sure wouldn't presume to tell that package manager how to
organize its repositories.
Nemokosch I mean, `use Digest::HMAC` is okay. `zef install Digest::HMAC` is not okay. 11:31
nine You said "Now, tell me a language", I did, and suddenly that wasn't good enough anymore. That's the definition of "moving goal posts".
Nemokosch No, you exploited that I didn't explicitly say "another language" because that seemed like common sense. 11:32
nine Why wouldn't it be?! Should I now guess which distributions contain the module I need? I don't _care_ about distributions. I care about modules. That's what I know and that's what I tell zef.
I did name another language: Perl
Nemokosch Raku itself started off as Perl 11:33
nine So what? It is a different language.
Nemokosch that's not "another language", that's where Raku probably directly inherited this behavior from. Also, that's the language Raku intended to FIX.
nine Ruby is closer to Perl than Raku is. Does Ruby count as another language?
Nemokosch Does Ruby do this? 11:34
> That's what I know and that's what I tell zef. 11:35
what kind of usage is that even???
nine I know I need Digest::HMAC, so I run `zef install Digest::HMAC`. Plain and simple.
Nemokosch What you are going to install is a _Distribution_, though 11:36
nine So what?
Nemokosch That's the whole design of all ecosystems
nine Yes it is. Again, so what? I get what I need in the most simple way.
Nemokosch So what? So it's not sane to pretend to depend on individual namespaces.
But that's not a great default the least to say. 11:37
That's a hack.
nine That may be your opinion and of course you're entitled to that. Doesn't make it a fact though.
Nemokosch That's why I'm presenting arguments for that. 11:38
Because it definitely is more than "just" an opinion.
By the way: what even happens if I have a distribution called A and then expose namespace B? 11:39
when does this module install?
nine You mean like the Inline::Perl5 distribution containing a module called Inline::Language::ObjectKeeper? Simple: everything just works and users are happy. For 7 years now. 11:40
Nemokosch Now this is not an answer.
nine And when I finally get around to splitting that off into its own distribution everything keeps running and noone has to change a thing. Beauty.
What would be an answer?
Nemokosch do I write zef install A or zef install B or both, and what precedence do they have? 11:41
And for "everything works": everything worked for several years with Digest::HMAC as well, until one day it broke mysteriously, apparently thanks to this design of zef 11:42
nine I'm not 100 % sure, but I think both would work.
Nemokosch Look, if even you aren't sure, what does it tell about this resolution process...
nine With great power comes great responsibility. In the best case, the authors of both variants would coordinate better. Alternatively it's easy to fix on the user side by tightening up the dependency specification. 11:43
What does it tell? That I actually install most of my modules via zypper, not zef
11:44 Kaipei left
Nemokosch what even is zypper? 11:44
nine duckduckgo.com/?q=zypper&hps=1...amp;ia=web 11:45
Nemokosch Also, gotta be honest: it would probably help with design if those people who have a say and a way to change things at least used the thing.
because now it sounds a lot like "it may suck for all I care, I'm not using it anyway" 11:46
nine I have used it. A lot over the years. I just don't know zef's full behavior by heart.
Nemokosch the most common use case (resolving installation by name) shouldn't even require knowing zef's full behavior by heart. That should indeed be something that just does the right thing. 11:47
nine Citation needed 11:48
How did you determine that zef install <distribution-name> is even a common use case?
Nemokosch Is this a sincere question or not?
Because I fail to believe it is. 11:49
nine it is
Nemokosch It's on the page of basically every ecosystem entry, and it's basically the one and only command you run to get something installed? 11:50
I don't know, it's hard for me to believe you would ask the same thing for npm, pip, or even apt and dpkg
nine I go to modules.raku.org (note, modules, not distributions.raku.org), look for a module, zef install <that-module's-name>. 11:52
As for your non-believing. I run `zypper install 'perl6(The::Module::I'm::Looking::For)' and get it installed. 11:53
11:54 Kaipei joined
Nemokosch funnily enough, modules.raku.org also lists distributions, not modules 11:54
nine Maybe. I haven't memorized that tools full source code either.
11:55 jpn left
nine But now that you mention it, yes I believe it does. And I've noticed that in a very negative way. Because when looking for a module, I sometimes have to trim down the name to hopefully arrive at a distribution name so it finds it. 11:55
Nemokosch But then please don't try to turn everything inside out either. These are heavily overloaded terms, I can very much imagine that an average user just wouldn't notice the difference 11:56
I can tell you for sure that I haven't used the word "distribution" in this context as much as I did today in one year and a half spent with Raku 11:58
inb4 no, not because I don't care about distributions
but because you take it for granted that they are the units you care about when retrieving code from others, so why even distinguish
12:00 reportable6 left 12:02 jpn joined 12:03 reportable6 joined
Actually, there isn't even an ecosystem that can show you a module on deeper level than "it's in this META file, it links to this path" 12:03
nine metacpan does it for Perl, as did the original cpan 12:08
The ~ 2 people who implemented websites for searching Raku modules haven't implemented it this way. Presumably because the underlying data format makes what's currently implemented just easier. 12:10
Nemokosch This is not the website's fault, there is simply no more data for a "module" in the ecosystem 12:11
not without exposing the artifacts as source code
12:12 jpn left
nine Again, not true. It could easily display the module's documentation (POD) by default. Just like metacpan. 12:13
12:13 jpn joined
Nemokosch _as long as you have access to the source code_ 12:17
that ecosystems only vaguely store, inside some tar typically
that's something you can only do in any of the ecosystems if you start to act upon a distribution 12:18
12:20 alfonsox joined 12:28 jpn left
By the way, another desperate question appeared to me 12:30
what if Digest and Digest::HMAC were distributions of the same author, and possibly even happened to have the same version?
do we get a collision one layer down?
nine Then that's just plain stupid of that author. As I already said: the best way to fix this is for authors to coordinate and not release modules with the same short name and different APIs. And if the APIs differ (e.g. because that new one just is superior and the way to go in the future), at least assign different API versions. That's what we have them for. 12:47
So if the author of the original Digest::HMAC agrees that his API is deprecated, the new one just needs a higher API version and users can specify that version. Problem solved. 12:48
grondilu Namespaces can be a source of conflict. Ideally people find an agreement but that can't always happen. I don't mind changing the name of my module, but I'll wait to see if the community really wants me to. 12:51
12:52 jpn joined
HMAC is not *really* a digest function anyway, so I'm not sure it made so much sense to give it its own module. 12:55
Nemokosch Okay, following the same logic: it's just plain stupid of the user to not realize that Distributions are the unit of sharing code, and therefore depending on modules/namespaces directly makes no conceptual sense. 12:57
Now, this is the embraced default of zef.
Let me say it one more time: it's okay if CompUnit resolution faces these problems. But that zef mimics this behavior is just insane. 12:58
zef CANNOT install "module"
yet it pretends to do that by this hack of reading the META6 file provides section 12:59
nine The thing is: as a user I don't care about distributions. I know I need Cro::HTTP::Server. Why should I have to guess which of the 7 distributions that the whole of Cro is split into contains it? And what if the authors decide to re-distribute those modules? Do I then have to re-learn my internal map?
grondilu It sure feels weird to mark a module (that is somtething with a ::) as something you could import directly from a module repository. It's as if you were importing a file directly from a linux package manager.
Nemokosch nine: then let me tell you that you are weird for a user
not representative whatsoever 13:00
If your point were that Cro is distributed in a bizarre way, I would agree. It's sadly a quite bad example 13:02
grondilu In linux when you want say a lib file, you search with your package manager which packages contain such file, and the package manager gives you a list. If you want to install a raku module without knowing in which repo it belongs, I think you should do something similar.
nine grondilu: but I literally do `zypper in 'perl6(Cro::HTTP::Server)'` and get that package installed. 13:05
tellable6 nine, I'll pass your message to grondilu
nine Nemokosch: yeah, calling the other just weird has always improved discussions... Arguably that's usually a clear sign that one has run out of good arguments. 13:06
tellable6 nine, I'll pass your message to Nemokosch
13:08 jpn left
nine Nemokosch: and yes, so far you have just not managed to demonstrate why dependencies should be stated in the form of distributions. You have yet to name one advantage, let alone enough for it to be worth changing everything to that model. On the other hand I have told you the advantages of the current model, which you don't even consider, but just dismiss them as me being weird. 13:10
tellable6 nine, I'll pass your message to Nemokosch
Nemokosch nine: it's interesting because I would say the same thing about you. I said that distributions are the actual unit of sharing code, they are the ones ecosystems reason about, that's how you can get proper, transparent name conflicts, sane lookups when you install distributions anyway, and not modules. And what do I get in return? You personally want to install stuff on a per-namespace basis, and anyway, you don't 13:15
let alone stuff like "is zef install even a common use case" and "of course there are languages that do that: Raku and its ancestor" 13:16
nine That distributions are the actual unit of sharing code is just a fact. That does not constitute an advantage to the user. So what if a whole distro with some other modules get installed? That doesn't hurt, so I don't care as a user.
Nemokosch I'm still wondering if Ruby does that, if as you say "it's closer to Perl than Raku is"
nine That distributions are what ecosystems reason about is an implementation detail. Again, not an advantage to the user. 13:17
That this would fix name conflicts is something you simply did not say. That first appeared in your "summary".
If you're wondering about Ruby, why don't you look up its documentation? 13:18
So the only real advantage you claim is that it'd avoid name conflicts as that one with Digest::HMAC. Ok, that's something worth discussing. And yes, that would be one way to avoid conflicts. But then, how do you solve the problem of distros becoming unmaintained? In our current model, someone else can simply upload a competing distro that contains a fixed version of the module. 13:20
Nemokosch no, that's not what they reason about as an implementation detail. That's the interface itself. 13:22
13:23 djerius left, jpn joined
that's what zef itself can look up and install, but hides it behind _the actual implementation detail_: namespace->compunit layout within a packaged distribution that is going to be installed 13:23
nine Again: what is the advantage to the user? 13:24
13:25 djerius joined
Nemokosch that they get what they asked for! 13:25
nine We're not creating systems for the purity of thought. We are creating systems for helping our users.
Nemokosch they ask for a distribution, not a namespace!
that's literally how it works everywhere!
nine Which has already been demonstrated to you to not be true. That you keep making that claim shows that you are not discussing honestly. So that's where I'm out. 13:26
Nemokosch no, it wasn't demonstrated - you personally turned out to be a counterexample. How does that matter?
You yourself said that you weren't even an ardent zef user. 13:27
nine No, I named Perl as a counter example. 13:28
I also told you about zypper and how it's used.
Nemokosch Raku inherited this behavior from Perl. Is it honest that you act as if you didn't know Raku started off as the next Perl?
13:29 jpn left
nine I never claimed that. 13:29
Nemokosch Also, as the _fixed_ Perl, which I cannot emphasize enough.
Being like the language you were meant to fix is not an actual honest counterexample.
nine And of course Nemokosch is the sole authority on what is honest and true. Yeah, sounds like someone to have a productive discussion with. 13:30
I'm happy to discuss how to improve Raku and it's ecosystem for real users in the real world. I won't waste any more time discussing wishes in a fantasy land where e.g. Perl or zypper are not allowed to exist because they don't fit someone's narrative. 13:31
Nemokosch No, obviously that has to be you 🤦‍♂️
If you honestly don't see how Perl isn't "another language" in Raku's historical context, and therefore is less valid as a "counterexample" than literally ANY other language - then the problem is somewhere else. 13:33
Also, it's frankly derogatory that I asked actual questions that were sparked from an actual real-world problem and you do everything to render the questions themselves invalid. 13:34
nine It's quite telling that you didn't react in any way on my question about how your proposal helps with the problem of distros becoming unmaintained. That instead you keep arguing about semantics and definitions makes it rather obvious to me that you don't want to openly discuss, but simply have your way. That's corroborated by your constant use of loaded language, calling everything but your proposal "insane" 13:37
or "weird".
Nemokosch Not "everything" but things that everyone else avoided and which is heavily backed up by the way all Raku ecosystems are composed. 13:38
Also, "distros becoming unmaintained" was never a problem - as illustrated by my takeover of HTML::Tag. Haven't I said that, really. 13:39
In fact it provides for a good example for not pinning auth for each and every module out there - but yeah disclaimer, that doesn't seem to be the main topic at the moment. 13:40
13:41 jpn joined
It's rather that I honestly wasn't ready for someone not only accepting that the identity of a distribution comes from the exposed namespaces - but even stubbornly insisting on that being the right thing. Indeed, that came unexpected because I have never imagined that could be a thing. 13:44
Insisting that the deliberate choice of an author to bundle compilation units with shared resources and metadata, and uploading them as one entity of the ecosystem, is "an implementation detail". 13:46
13:46 jpn left
nine Which again I didn't. It would help wonders if you actually argued about what I said, not whatever you made out of it. 13:47
xinming SmokeMachine: Sorry, the yesterday example should be something like: `multi method inflate(Blob $value, :$to!) { $value }` not `$to.new: $value`, it seems the `$to.new: $value` version will cause Empty value 13:49
Nemokosch > That distributions are what ecosystems reason about is an implementation detail. Again, not an advantage to the user. 13:50
nine Yes, that's what I said. That does not even contain the word "author". 13:51
Nemokosch distribution = "the deliberate choice of an author to bundle compilation units with shared resources and metadata, and uploading them as one entity of the ecosystem"
nine That's your definition.
Nemokosch oh come on, this is really getting pointless
what is your definition then, dammit
It would really help if we could at least agree on the core concepts... 13:53
nine "A distribution is an archive of some form that can be used to install zero or more compilation units (each stored in a separate file), with any possibly associated files needed for execution." design.raku.org/S22.html#distribution
design.raku.org/S22.html#TERMINOLOGY 13:54
Nemokosch this pretty much backs me up though?
nine I said "that ecosystems reason about distributions" is an implementation detail. There's nothing keeping modules.raku.org's search from finding modules, except that this is simply not implemented. 13:55
Nemokosch a distribution is what has a one-to-one correspondence with a META6 file
nine I did not say that distributions themselves are an implementation detail.
Nemokosch I mean, this sounds half true. Yes, an interface for shared Raku content could work on a per-module basis... somewhat. If it has access to the META6.json files, it can build up a graph from that and index based on the exposed modules. However, modules don't have 1-to-1 correspondence to metadata, and all the rest about them is inside the source code (I suppose?) 13:58
13:58 jpn joined
so eventually it would work as good as redirecting you to the distribution that exposes that certain module - basically that's what zef does currently 13:59
Also, I think I have asked this at some point: is there a way to specifically ask for a distribution by its own name?
nine It's funny. On the one hand you say that Perl is not a valid counter example, as it is too closely related. On the other hand, you completely dismiss 30 years of experience with that model, even though the language is too closely related to be a counter example. It "could not...somewhat" work that way. It can. It has for decades in Perl.
Nemokosch it is not "too closely related" but literally the ancestor. Talking about quoting. 14:00
nine It's funny. On the one hand you say that Perl is not a valid counter example, as it is Raku's ancestor. On the other hand, you completely dismiss 30 years of experience with that model, even though the language is an ancestor and thus invalid as a counter example. It "could not...somewhat" work that way. It can. It has for decades in Perl. 14:01
Point still stands.
Nemokosch Also, looking at NuGet, npm, Maven, what even there is, they also have experience, don't they? And they didn't create a spinoff of themselves to fix things.
Well, then show me how it would work for Raku. I don't wanna go back to Perl. 14:02
+1: > Also, I think I have asked this at some point: is there a way to specifically ask for a distribution by its own name?
nine "Everyone else does it" has never been a valid guiding principle for Raku's design and I'm pretty sure it never will be as it's simply en.wikipedia.org/wiki/Argumentum_ad_populum
14:03 jpn left
Nemokosch Honestly, I don't care. At the end of the day, ecosystems are social. 14:03
Even if we absolutely neglect the possibility that they actually got it right and didn't have to fix themselves, it says something about people's expectations and THAT shouldn't be neglected. 14:04
ugexe Have you actually tried installing by distribution name?
Nemokosch That's what I thought I did every time until one day things broke down. 14:05
ugexe I’m on a phone so I can’t do a write up, but this conversation has happened before
Geth ecosystem/main: 2f73704fd6 | (Elizabeth Mattijsen)++ | META.list
Digest now lives in zef ecosystem
Nemokosch and apparently nothing changed
ugexe So you think you tried? 14:06
Nemokosch well, I hope this means that you have good pointers about the conclusion
Geth ecosystem/main: dd55bd4a9b | (Elizabeth Mattijsen)++ | META.list
ECMA262Regex now lives in zef ecosystem
ugexe as with most things there were trade offs to be made, particularly that the entire ecosystem listed their depends one way or the other and so to even create zef meant that had to work both ways 14:07
Nemokosch ugexe: I used to think I "tried". If I still thought I did, I wouldn't ask.
ugexe zef install zef
there is no module named ‘zef’ just the distribution
or Net::HTTP which has no module by that name 14:08
Nemokosch Okay, hold on, I need to think before drawing some stupid conclusion...
Is there a precedence between module names and distribution names? 14:09
lizmat distribution names are what you *can* use to install a distribution, module names can be used for both installing a distribution the are a part of, and can be used as a target in a "use" or "require" 14:11
*they
Nemokosch I get the first and the third part. 14:15
14:16 jpn joined
what exactly (well, "exactly" - from lookup pov) happens when someone writes `zef install Digest::HMAC`? 14:17
lizmat it looks for any distribution that has "Digest::HMAC" in its "provides" as a key, and looks for any distributions by that name, creates a list of distributions 14:18
if that list has 1 element, it installs that and its dependencies
if the list has 0 elements, it fails
Nemokosch So they end up in a shared list of candidates?
lizmat if the list has >1 elements, then it fails you needing to be more specific
the search is slightly more complex, as it works in ecosystem backend groups 14:19
I forget what the exact hierarchy is, and you can actually change that if you want
but basically, if "zef" finds one distribution, then that's it 14:20
14:22 jpn left
Nemokosch what I'm thinking is that IF one gave unconditional precedence to distribution names over module names, that would pretty much do 14:25
ie. module names would only be looked up if there is no matching distribution name
14:29 razetime joined
lizmat what would that bring? 14:31
14:36 jpn joined
Nemokosch In this particular example, it would bring that dependents of Digest::HMAC would find the distribution like they used to. In the broader picture, as opposed to niner's opinion, I think it's both more common and more reasonable to depend on distributions than "out-of-context" modules so I'd expect to prevent several other situations to this Digest::HMAC incident. 14:39
lizmat Well, I think in the Raku world you should *always* be as explicit as possible of what you want to load 14:44
14:44 jpn left
lizmat or instalL 14:44
so *I* *always* use :auth and :ver when it is possible to do so
and I think anything that runs in production, should be explicit in what it loads 14:45
Nemokosch that could probably a whole new discussion 🙂 14:52
For now, I have the following thought pattern, more or less: 14:53
1. there are several modules out there from earlier stages of Raku ecosystems, under various terms of maintenance, subtly put... like many of them are abandoned or undermaintained. However, they are there and often are even dependencies of other modules. 14:54
14:56 hythm joined
2. there are some more central modu... distributions, more accurately, also under varying conditions. Changes to them can easily lead to breakage of distributions that are hard to access or fix, and their sheer amount can get overwhelming anyway. 14:57
14:57 jpn joined 14:58 leah2 left
3. ultimately, while there are some causes that can break an old module that didn't declare its dependencies carefully enough (change of API, for example), and then there isn't much we can or even should do about it (I suppose? There could be some version guessing but that sounds very slippery). *However*, this "module collision" doesn't seem like a worthy reason for that at all. 15:00
And especially if we check out the "plot". 15:01
15:01 leah2 joined
There was a distribution called Digest that exposed several modules - but not Digest::HMAC. Somebody created a dependant distribution exposing Digest::HMAC, calling it Digest::HMAC. I think all of these steps make perfect sense. 15:02
A number of distributions ended up depending on Digest::HMAC. And finally, the author of Digest created a module within the Digest distribution, called Digest::HMAC, following the same convention. 15:03
15:03 jpn left
One can say that the authors of these two distributions should have collaborated better. But let's be honest with ourselves: do *we* collaborate that great, as in regulars of IRC, collaborators of raku-community-modules, commiters to Rakudo, whatever label you wish? I would argue that we collaborate somewhat but not sure we could properly prevent a situation like that among ourselves. 15:05
hythm FWIW, I have seen similar issue with NativeLibs, NativeLibs is `provided` with DBIish:ver<0.6.1> and lower versions. NativeLibs got removed from DBIish in later versions, but when a distrubtion depends on NativeLibs, DBIish was still being resolved as the dependency, b 15:13
ecause comparing DBIish version 0.6.1 with Nativelibs distribution verion '0.0.1` for example, the DBIish distribution always win. so I
ended up making Pakku look for a distribution with that name first, and only if it did not find, then look for provides
15:16 jpn joined
Nemokosch nice 15:17
NativeLibs is the module of Salvador Ortiz, right? 15:18
hythm I think so, the auth field is `github:salortiz` 15:20
ugexe so for some context: s22 talks about only module names in `depends`, and technically this makes perfect sense. As a slight aside, distribution names shouldn't really have :: in them (instead using -). Anyways panda (what ufo or whatever came before that) allowed both distribution names and module names as dependencies and thus the ecosystems had been built around that 15:32
from a pure design perspective current tooling shouldnt look for distribution names 15:34
but that also isn't very practical, i.e. listing every module (instead of distribution) you depend on in depends 15:35
note i do not say impractical though, just not very practical 15:36
Nemokosch what are distribution names even for, in that case?
ugexe well i misspoke a bit. there is the case when a distribution doesn't provide any modules 15:38
and that is still useful to query for
maybe this is a better way to put it...
when a user is requesting to install something explicitly, they probably mean the distribution. when describing what should be installed for building a dependency graph (META6.json depends), it should refer to the module names 15:39
15:43 jpn left
ugexe one way some of this cruft can cleaned up is with the transition to fez, or more generally to an ecosystem that enforce more control over namespaces (including what is in uploaded distributions `depends`) 15:48
Nemokosch There isn't like an ultimate solution, that's for sure. The `use` is gonna go for the module, that we can call a given.
From that perspective, it is, I would say, at least tempting to go for the same semantics with installation 15:49
However, I still fail to get the idea behind depending on modules/namespaces, when they aren't units of distributing functionality to the publicity. 15:50
ugexe having a bin/foo script that doesnt use any modules, providing a "pack" of modules like Task::Star 15:51
Nemokosch These are two distinct topics, aren't they. The second one is the one of concern at the moment. (First one: not all distributions are "depends-worth" - sure thing.) 15:56
The "pack of modules" is a pretty good point.
Even though I still find it very unrelatable to use namespaces (as opposed to distributions) as the entities for sharing behavior with other authors... I wouldn't say that the approach itself couldn't be turned functional. 15:59
It's just this "Digest::HMAC incident" (and apparently the "DBIish incident") tells me that this approach has little awareness within the ecosystem, as things stand. So even if this is how things have been working technically, the ecosystem doesn't reflect it, basically on any level. 16:02
so the way this dichotomy happens to me isn't "for what benefit should the status quo (implementation pov) changed" in the first place 16:04
ugexe doesn it? if it had installed its possible the system would be in a state where raku tries to import things incorrectly
its going to potentially break, it just breaks early in this case 16:05
Nemokosch from what I see, it's much more like "for what benefit should the status quo (conceptional pov) changed *to match the implementation*"
and no, inb4 it's apparent that this isn't something that only exists in my mind 16:06
and not just "for what benefit", also "at what cost" - we cannot even estimate regarding the modules that have spent, say, 5 years out there, with little to no maintenance, and kept working under similar terms 16:07
ugexe ecosytems can enforce these rules, and thats the appropriate place for it to occur
Nemokosch > doesn it? if it had installed its possible the system would be in a state where raku tries to import things incorrectly 16:09
I mean, that's basically what happens now as well. The test fails, not the resolution, even though the resolution was wrong.
ugexe luckily it had tests to fail 16:11
Nemokosch but unfortunately it failed on the order of resolution 16:12
ugexe ye olde no auth/ver/etc 16:13
Nemokosch funnily enough, the valid naming rules could not even guarantee this wouldn't happen, and then good old "DIHWIDT" remains 16:14
so auth/ver/etc doesn't even guarantee to help - but okay, granted, in this case, it could have helped. What does that change about the situation that a huge proportion of distributions 1. doesn't use those 2. treats dependencies as distributions, not modules? 16:16
lizmat why doesn't auth/ver/etc not guarantee to help? 16:17
ugexe a good enough proportion does use those and treats them as module as well. so how do not break the world?
Nemokosch lizmat: because there still can be two distributions with different names but otherwise same metadata that try to provide the same module 16:18
ugexe there are also things like github.com/rakudo/rakudo/pull/5060 which would depend on module names
lizmat not if they're using zef 16:19
Nemokosch ugexe: distribution names to take precedence over module names?
lizmat that's why we need to get rid of p6c and cpan
ugexe if your zef config only contained trusted ecosystems you could have it so two distributions in this single ecosystems couldnt have a shared namespace 16:20
and we are moving in that direction
Nemokosch where does that enforcement happen?
ugexe it doesn't yet, but thats the place it can happen when/if/already some critical mass is reached 16:21
Nemokosch I think the problem really revolves around this silent agreement that `use` and zef lookup/installation MUST, at all costs, have the same semantics, even though they operate on different conceptual levels. 16:23
`use` is basically dedicated for module inclusion. `zef` acts on distributions. 16:24
dependency resolution is much more in the `zef` territory than in the `use` territory 16:26
Ironically enough, if you were to retrieve a module from someone else, I don't think you can even get to auth-version sort of metadata, WITHOUT looking at a distribution. There is just no other way to get to this piece of information - or is there? 16:30
16:31 Kaipei left
ugexe i think its important that if you see something in `depends` that you can `zef install $that-thing`. however, its also important for META6.json depends to list enough information to actually build a dependency graph, and that requires module names (as s22 says) and not distribution names 16:38
Nemokosch Trying to break this down to atomic pieces. 16:41
16:41 jjido joined
> build a dependency graph 16:42
what is a "dependency graph" in this context?
I can't see this phrase in S22
again, naively I would think of something on "ecosystem level", not "compunit level" 16:43
ugexe how can it be on the ecosystem level if i use a private repository like a darkpan for some modules but not others? 16:44
a dependency graph is a tree of all the dependencies and transitive dependencies of something 16:45
Nemokosch tbh even in that case, I guess distros can be installed, not modules 16:46
so the dependencies would still be distros, and this is what I meant
a dependency graph could be understood in this context as well - khm, npm 16:47
ugexe for naive things yes 16:49
Nemokosch I wanted to ask if "its also important for META6 (...)" is an opinion, a design principle, a technical necessity etc 16:52
But it's hard to ask that without knowing why distribution names aren't sufficient for that 16:53
17:02 ab5tract joined
ugexe one answer is that is what github.com/Raku/old-design-docs/bl...on-manager says 17:05
at some of my jobs i would find us shadowing/patching only some modules of a distribution, and indeed other workflows may depend on a module that isn't part of a distribution 17:13
although yeah you would not zef install such a thing (well maybe, but it would use emulates/superceded-by or some other theoretical nyi meta6 feature) 17:14
but for what gets listed in META6 it makes sense in that regard
Nemokosch well, if the intention was always to resolve compilation units (which still seem too low-level to be of exclusive interest of an author but so be it) - it makes you think how we ended up in a situation where distribution names like to pretend to be module names? 17:21
ugexe because thats how it was implemented in ufo/panda
and how the ecosystem at the time was doing it 17:22
Nemokosch unfortunately, this intermixing continues, probably due to sheer ignorance of the intention 17:23
(and this is where the unintuitiveness of the intention also doesn't help)
17:27 alfonsox left 17:33 razetime left
I keep thinking about this and the "recommendation manager" desperately sounds like a peculiar feature imposed as the rule - wouldn't be the first occasion... 17:41
to be able to look up a distribution by a compilation unit of it is nice, absolutely
nevertheless, the straightforward behavior is to look up a compilation unit by a compilation unit, or to look up a distribution by a distribution 17:43
17:48 ProperNoun left 17:49 ProperNoun joined 17:51 jpn joined
oh by the way... can the "provides" section specify something like "I only provide this if you refer to me by the fully specified name"? 17:51
17:55 jpn left 17:56 jpn joined 18:00 reportable6 left 18:02 reportable6 joined 18:14 grondilu joined
grondilu so I inherited a class from Mix and noticed the TWEAK submethod wasn't executed anymore. 18:15
tellable6 2023-01-08T13:05:08Z #raku <nine> grondilu: but I literally do `zypper in 'perl6(Cro::HTTP::Server)'` and get that package installed.
grondilu m: class :: { submethod TWEAK { print "tweaking" } }.new 18:16
camelia tweaking
grondilu m: class :: is Mix { submethod TWEAK { print "tweaking" } }.new
camelia ( no output )
grondilu m: class :: is Int { submethod TWEAK { print "tweaking" } }.new
camelia ( no output )
grondilu :🤔
m: class Foo {}; class :: is Foo { submethod TWEAK { print "tweaking" } }.new 18:17
camelia tweaking
18:22 grondilu left, jpn left 18:26 jpn joined
SmokeMachine xinming: $to.new doesn't seem to return empty here... usercontent.irccloud-cdn.com/file/.../image.png 18:30
xinming: is there an example code where it's empty? 18:51
Nemokosch grondilu: does your class itself have a TWEAK submethod and that doesn't get executed? 19:05
19:26 linkable6 left, evalable6 left 19:28 linkable6 joined 19:29 evalable6 joined 19:33 Kaipei joined 19:54 abraxxa-home joined 20:07 Sgeo joined 20:12 jpn left 20:53 jpn joined 21:06 ab5tract left 21:10 vrurg_ joined, vrurg left 21:16 jpn left 21:19 jpn joined 22:06 Maylay left 22:07 xinming left 22:18 jpn left 22:33 Maylay joined 22:39 justache is now known as justReddy 23:04 abraxxa-home left 23:26 sena_kun left 23:32 jjido left
is it possible to create coercion to an enum? 23:32
from a type you cannot/don't want to extend, to an enum
[Coke] i don't believe so, and i don't think it would mean anything useful - what would the enumerated values be? 23:55
23:59 kjp left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!