🦋 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.
justthisguyaz OK. Any pointers for that? 00:02
Voldenet if I grasp it correctly, just implement Zef::PackageRepository, install it and modify zef's config 00:13
github.com/ugexe/zef/blob/782cdda3...akumod#L64
justthisguyaz Thanks!
Voldenet it has some docs at least 00:14
it's possible that simply Zef::Repository::LocalCache would be enough for this use case 00:16
00:17 hythm joined
Voldenet though I'm unsure what it does 00:17
justthisguyaz OK, I'll take a look. 00:18
ugexe ::LocalCache can serve as inspiration, but i think for a darkpan type thing people want something to reinstall the .tar.gz distribution whereas ::LocalCache keeps a copy of the extracted and post-build step distribution 00:22
00:31 Manifest0 left
hythm justthisguyaz also If you are open to other package managers, you can do that currently in Pakku (I'm the author of Pakku), assuming "/my-local-repo" directory contains Raku distributions, one can run `pakku config recman MyLocalRepo set location /my-local-repo`, and after that all distributions inside that local directory will be discoverable and 00:34
installable using Pakku.
justthisguyaz Thanks hythm! Good to have options. 00:35
00:39 buildable6__ left 00:42 buildable6 joined 01:41 hythm left 01:42 buildable6 left 01:44 buildable6 joined 02:41 dbonnafo joined 02:44 buildable6 left 02:45 buildable6 joined, dbonnafo left 03:02 dbonnafo joined 03:07 dbonnafo left
tonyo melzhik: danke 03:29
justthisguyaz: there's also a module called `envy` that will let you manage those repos similar to pinto 03:31
03:43 dbonnafo joined 03:45 buildable6 left 03:47 buildable6 joined 03:48 dbonnafo left
Xliff .seen japhb 04:04
tellable6 Xliff, I saw japhb 2023-10-27T02:52:21Z in #raku-dev: <japhb> Awwww
04:25 dbonnafo joined 04:30 dbonnafo left 04:47 buildable6 left 04:48 buildable6 joined 05:48 buildable6 left 05:49 buildable6 joined 06:26 dbonnafo joined 06:31 dbonnafo left 06:47 dbonnafo joined, abraxxa joined 06:49 buildable6 left 06:50 buildable6 joined 06:52 dbonnafo left 07:15 dbonnafo joined 07:22 Manifest0 joined 07:34 Sgeo left 07:37 sena_kun joined 07:46 abraxxa left 07:47 abraxxa joined 07:50 buildable6 left 07:53 buildable6 joined 07:57 dbonnafo_ joined, lichtkind joined 08:00 dbonnafo left 08:05 dbonnafo_ left 08:20 jpn joined 08:43 jpn left 08:52 buildable6 left 08:53 buildable6 left 08:55 buildable6 joined 09:06 guifa left 09:07 guifa joined
nemokosch hythm: I was just thinking about it a couple of days ago - how do i obtain the distributions locally in the first place? 09:26
tellable6 nemokosch, I'll pass your message to hythm
nemokosch I mean, it's not very fun if one has to go through all the dependencies manually 09:28
09:32 jpn joined, TieUpYourCamel joined 09:55 buildable6 left 09:57 buildable6 joined
tbrowder__ hi, is there an IRC for the RSC? 10:23
lizmat #raku-steering-council 10:24
tbrowder__ thnx. ok to blather on it?
serious only 10:25
lizmat yup, that's what it's there for
tbrowder__ what is use case for local repo collections, something like local cpan? classified systems, cutoff from internet, etc.? 10:26
lizmat those are two use cases, yes 10:27
10:33 sena_kun left
nemokosch cutoff from internet in my case 10:39
data export is forbidden but you can import what you need 10:40
so it could work if there was a way to "localize" the repos and copy them to the network
10:42 Manifest0 left 10:57 buildable6 left, buildable6 joined 11:05 peder left 11:10 peder joined 11:57 buildable6 left 11:58 buildable6 joined
lizmat And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/10/30/2023-...ngly-good/ 11:59
ugexe the zef cache used to keep one from redownloading distributions but it ultimately was more trouble than it was worth due to people not bumping versions and wondering why they would get an old version 12:01
The see ecosystem 12:08
the zef ecosystem plugin allows has an option to load from a loca mirror that emulates the zef ecosystem layout on a local file system 12:09
tony-o would know more about that though 12:10
As far as how to distribute all distributions in all exosystems… that is a bit harder. Cocoa pods or whatever used to use GitHub to do something similar but were eventually stopped from doing it once their repo started using a certain amount of bandwidth / resources 12:13
tbrowder__ i asked about this before deleting modules from Fez/Zef and tonyo said not possible. 12:14
ugexe So it is probably best to not build on a “clone a repo with every distribution artifact” system
tbrowder yeah that’s mostly correct. But people still use p6c and cpan where you can do those things 12:15
tbrowder__ but i would like someway to mark a published article as not recommended so zef, among other searches, can somehow use it to filter author-approved modules. 12:19
12:20 lichtkind left
tbrowder__ i thought the goal is to use fez in lieu of the otthers 12:20
for all of its safety features, etc. 12:21
s/article/module/ 12:22
ugexe That is correct. But if some modules are still on p6c and cpan and they are dependencies of a distribution that is in the zef ecosystem then it still needs to some from somewhere 12:24
12:26 teatime joined, teatime left 12:30 edr joined 12:32 phogg left
ugexe We also shouldn't be doing things like using a mixed ecosystem source to source distributions from secure ecosystems like the zef ecosystem other than as a backup 12:34
For example I can upload a distribution to cpan or p6c that has a zef auth. That means relying on the mixed ecosystem to know which distribution came from where isn't so easy as just filtering on auth 12:36
tbrowder__ if i were emperor i would order cpan and p6c raku modules to be immediately be removed from there and moved to zef. 12:37
nemokosch In any case, for me it would be quintessential to be able to pull distributions in persistent and moveable way 12:38
Better than just "try and clone everything"
ugexe i wasn't referring to try and clone everything, i'm talking about like just cloning the REA
which would be a single clone
I talked with tony-o before also about adding an endpoint to fez to download an index and latest version of every module, but there were still a lot of details to work out (like also including all the versions that other things in that list depend on) 12:39
tbrowder__ but somehow i think the raku community should eventually ban continued use of p6c and cpan. 12:42
for anything raku related
ugexe yeah, github.com/Raku/problem-solving/issues/316 mentioned ending support on Jan 1 2023 but alas 12:46
just ending support would really only mean to stop indexing p6c and cpan though, for now anyway 12:52
until important modules like openssl etc are moved
otherwise zef still needs to source from p6c for things like that
that being said, i suspect most things have been moved over already so there probably isn't too much down river distributions left to go 12:53
12:58 buildable6 left 13:01 buildable6 joined 13:05 buildable6 left, buildable6 joined 13:10 buildable6 left, buildable6 joined 13:23 jgaz joined
ugexe www.codeavail.com/blog/raku-progra...-language/ reads like it was written by an LLM 13:28
it says some form of "Raku, formerly known as Perl 6" at least 4 times 13:29
El_Che there should be a memo to get rid of the Perl 6 part, muddling the PR waters 13:34
ugexe yeah... right now chatgpts favorite thing to say about raku is "Raku, formerly known as Perl 6," 13:36
El_Che indeed 13:37
nemokosch not gonna lie, cloning the whole REA seems... very overboard 13:41
and like absolutely not scalable 13:42
ugexe oh certainly. just there have been other package systems (for other languages etc) that did something similar at one point
and is attractive in its simplicity. but indeed there are many problems with it such that it isn't something i'd recommend either 13:44
14:01 buildable6 left 14:02 buildable6 joined 14:04 kst` left 14:09 raiph joined 14:15 lichtkind joined 14:24 japhb joined
ugexe i should combine CompUnit::Repository::Lib with CompUnit::Repository::Tar one day 14:34
where you point this "CompUnit::Repository::TarLib" at a directory of tar files instead of how you point "CompUnit::Repository::Tar" at a single tar file 14:35
15:02 buildable6 left 15:03 buildable6 joined 15:07 buildable6 left, buildable6 joined 15:37 phogg joined 16:03 buildable6 left 16:04 buildable6 joined 16:21 raiph left 17:02 derpydoo left 17:04 buildable6 left, derpydoo joined 17:05 buildable6 joined
tonyo REA encompasses all of the ecosystems but it removes some of the securities in zef 17:29
18:05 buildable6 left
tonyo tbrowder__: i like the idea of flagging an uploaded module as deprecated in the ecosystem and that skirts the "breaking" aspect of deleting modules 18:07
tbrowder__ 👍🏻 18:08
ugexe i think in most ecosystems deprecation happens on the namespace level
tonyo say more
ugexe i.e. you can deprecate all your previous versions
18:08 buildable6 joined
tonyo oh, yes - possible here too but just syntactic sugar 18:08
oh, yes - possible here too but just syntactic sugar 18:09
eg, you don't want that behavior if you have a libssl binding module and you've built against version X, new major version goes against Y. some point in the future you're building against Z. X is found to have a serious security flaw - you don't want to deprecate Y too
ugexe i mean it is sort of implied by bumping the minor version though 18:10
what is the difference between marking 0.2.0 as deprecated and releasing 0.2.1?
tonyo maybe unmaintained is a better word for the meaning 18:11
ugexe all distribution versions outside the latest are not maintained
thats why i mentioned being able to deprecate previous versions, i.e. deprecate the entire namespace
tonyo i disagree, if you've built 0.2.1 you're still technically maintaining 0.2.0
but you need a way to inform users that you're not recommending that module any more 18:12
ugexe you could only be maintaining 0.2.0 if you release 0.2.0.1
18:12 buildable6 left 18:13 buildable6 joined
tonyo if 0.2.1 is built on top of 0.2.0 you're still maintaining code that was release in 0.2.0 18:13
ugexe then what reason is there to deprecate 0.2.0 instead of just releasing 0.2.1
which already implies that
tonyo the reason is that you're recommending to users they should _not_ use that module anymore
EG a serious bug was found and they should either upgrade or find an alternative
ugexe that is what the 0.0.1 point release implies 18:14
tonyo yes but it's not explicit
0.2.0 may still work fine and if you're pinning dependencies on version then that one should still be fine until the author recommends you find something else 18:15
ugexe but what use is it then? if someone pins their version on 0.2.0 a package manager shouldnt ignore that because it is marked as deprecated 18:16
tonyo it needn't ignore it but it can alert that some discretion should be used by the installer
ugexe cached versions of that distribution would no longer be accurate either, as the meta data indicating the deprecation would have to be added after it has already been released and considered immutable 18:17
tonyo eg in the SSL module example you _could_ put deprecation notes
it only needs to exist in the index
18:17 buildable6 left
tonyo not in the dist itself 18:17
18:17 buildable6 joined
tonyo and that can be handled by the indexer/ecosystem, the json file ecosystem stuff contains meta data about the dist, not exactly what is in the dist itself 18:18
not exactly what is in the dist/META6 itself*. as an example there's no way to know the download link prior to verifying and indexing 18:19
ugexe i'm also a bit lost no what the module installer is supposed to do with that information 18:20
like that is a module author problem
tonyo it's an end user concern
if they search and find HTTP::Server and read a little they find they can couple that with SSL, so they go to install HTTP::Server that uses a compromised SSL version, they should be alerted when it's installed 18:21
in the search if they see it's not recommended by the author any more it also saves them reading anything of it
18:21 buildable6 left
ugexe i'm not sure i agree with that. the end user should not be troubled by authoring issues 18:21
18:21 buildable6 joined
tonyo it's not an authoring issue 18:22
ugexe some module author is the only one that can change that dependency as it is declared
tonyo you can't go back and update 0.2.0 to rely on a bumped SSL version
ugexe true, which someone pointed out that perhaps we should be pinning on e.g. 0.2.*
tonyo yes, in that way they need to fix it but you still need to be transparent with the user that what they're installing has been put in some state by the module author 18:23
daniel asked and i responded with that, but it's still an end user concern
at some point in the dependency chain they need to know that a module is not recommended by its author anymore 18:24
18:26 buildable6 left, buildable6 joined
ugexe yeah if it isn't in the actual meta6.json data it makes more sense to me 18:41
18:44 sena_kun joined
[Coke] different use case, what if it's already installed and now it's deprecated. 18:51
19:05 justache is now known as justHaunted 19:08 buildable6 left 19:10 buildable6 joined 19:16 dbonnafo joined
ugexe that seems like something that would work in sort of auditing mechanism 19:26
tonyo yea 19:45
agreed, maybe just a command in the great zef, `zef audit`
or whatever
19:47 jpn left 19:50 jpn joined 19:58 jpn left 20:07 derpydoo left 20:10 buildable6 left 20:11 buildable6 joined 20:15 buildable6 left, buildable6 joined 20:26 TieUpYourCamel left 21:11 buildable6 left 21:12 buildable6 joined 21:23 derpydoo joined 22:12 buildable6 left 22:15 buildable6 joined 22:18 hythm joined 22:19 buildable6 left, buildable6 joined
hythm nemokosch: yes you still need to get the distribution locally, but for example if you have a few local distributions in `/local-dists` and they depend on non-local distributions, these deps will be resolved from the online recommendation manager, you don't need to download the deps as well. 22:19
tellable6 2023-10-30T09:26:56Z #raku <nemokosch> hythm: I was just thinking about it a couple of days ago - how do i obtain the distributions locally in the first place?
hythm for the scenario were internet is cutoff, you will need to get these dists locally oneway or another. either by downloading them and storing in local path eg. '/local/dists', or better run a recommendation manager service (github.com/hythm7/recman-simple) on localhost, then configure Pakku to use the local recommendation manager instead of 22:20
the default one that requires internet access
nemokosch well, how do I get them locally? 22:21
this is my problem specifically. I don't want to go around collecting 50 distributions, but I also don't want to outright download the whole ecosystem
hythm why not just 'pakku download dist1 dist2....' , they will be downloaded to temp directory 22:23
dependencies will not be downloaded though, 22:24
Voldenet perhaps `pakku download $(zef depends cro)` 22:28
I didn't test it, perhaps the format of zef deps is not going to be usable here 22:29
22:33 Sgeo joined
hythm That will work actually. (if there is no `===> Updating fez mirror:....` in the output of `zef depends` command) 22:37
22:40 dbonnafo left
Voldenet I think zef outputs the "Updating fez mirror" to stderr 22:43
hythm yes, just tested it and it worked gist.github.com/hythm7/6c89d1b079e...fc18859530 22:47
22:48 bloatable6 left, bloatable6 joined, bisectable6 left, bisectable6 joined
tonyo why not juse use zef at that point? 22:50
23:01 sena_kun left 23:02 sena_kun joined 23:11 rba_ joined 23:12 mark22k9 joined 23:13 Dominika joined 23:14 [Coke]_ joined 23:15 sdomi left, [Coke] left, itaipu left, thowe left, jgaz left, rba left, rba_ is now known as rba, jgaz joined, buildable6 left, mark22k left, mark22k9 is now known as mark22k 23:16 itaipu joined, buildable6 joined
nemokosch frankly, in any case, it feels like "localizing" (caching, whatever) a distribution to the point that it works (ie. obviously with dependencies) shouldn't be this complicated 23:20
23:20 thowe joined
ugexe I mean zef already does that 23:21
It doesn’t save the .tar.gz file, and the directly it uses can’t just be moved
nemokosch it has to anyway
but it's not a proper interface
ugexe how so 23:22
github.com/ugexe/zef/blob/main/lib...he.rakumod
nemokosch as you point out, it's just some sort of "hidden" directory where everything goes and you have to cherry-pick from that and hope for the best 23:23
ugexe you can use that class by itself
and set whatever directory you want
nemokosch I wouldn't say this is user friendly but honestly, I wouldn't even say this is user scope 23:26
Voldenet it's not as easy as `zef download-tree –target=./raku_modules rak`
though honestly various caches in other package systems works the same way 23:27
nemokosch at the end of the day, node dependency management wasn't such a bad thing 23:28
ugexe lol 23:29
Voldenet you mean arbitrary npm-cache folder? 23:30
tonyo the node deps stinks 23:31
nemokosch I mean the default npm use case with node_modules is literally movable
Voldenet heaviest_objects_in_the_universe.jpg
nemokosch well you haven't seen rather complex Raku distributions 23:32
tonyo that wasn't really an intended design feature. the number of times i've had to delete that folder and re-download everything is close to the number of times i've repicked up working on a project
or close to the number of times i've updated main at work after more than 3 days 23:33
nemokosch in any case, it just works
Voldenet I work on a few git branches at the same time a lot, so
ugexe It just works. Sometimes 23:34
Voldenet having N duplicates of binary blobs isn't the best
tonyo in your experience, in mine it's a terrible mess (and i use it almost every day of work)
nemokosch it's not the only time good old node_modules just works for something that has an unconvincing and overcomplicated solution in Raku land
tonyo lol. 23:35
nemokosch but it's definitely the most relevant for my particular situation
ugexe Implement something simpler and make our lives easier
nemokosch for now, I am the user
and as a user, maybe I get to say that my use case for work (which doesn't seem completely unheard of either) is completely unsupported 23:36
the advice is akin to "write it yourself" already
ugexe Sure. And I can say please solve the difficult problem for us if you have the insight to do so
tonyo it's akin to, here's some tools to help you do what you want. not write it yourself. 23:37
ugexe It can be something small and simple to demonstrate how it could work. It doesn’t have to be a full fledged core ready PR 23:39
nemokosch if we consider APIs to program tools
Voldenet ngl it would be nice to have some built-ins for "raku_modules"
23:40 lizmat left, lizmat joined
nemokosch and really, what boggles my mind is that zef, the CLI tool, definitely has to retrieve all the dependencies locally 23:40
in some order, it definitely must make all the necessary steps to establish movable local distributions 23:41
tonyo is your q how to make that possible?
23:41 dbonnafo joined
tonyo just keep a .lib folder and use raku -I.lib ... 23:41
nemokosch well, my question is, what do you do if you want Raku distributions from the ecosystem on a machine that has no access to the internet 23:43
tonyo assuming you had some media to transfer?
Voldenet copy ~/.zef
tonyo i'd probably nab the dists, transfer them via usb key _or whatever_ and then unload them into a local lib..short of that you could use envy and do zef install --deps-only --to=envy#your-cache . and then use envy's tool to tar/gz on that to move it 23:45
(the tar/gz would be manual but envy will tell you where the dir is iirc)
nemokosch what is this envy?
ugexe the Zef::Repository:Ecosystems supports a `uses-path` option too
Voldenet raku.land/zef:tony-o/envy
tonyo it
ugexe but you can't have a directory of extract modules that are movable
extracted^ 23:46
tonyo it's like venv
does the precomp fail?
err what fails in that?
oh, misread - disregard
ugexe i mean you can, and it would work some/most of the time
23:46 dbonnafo left
ugexe but a good amount of the time you have build artifacts 23:47
stuff in C or makefiles
with absolute paths
tonyo is there stuff that installs not to resources?
ugexe technically yeah, but i think we can ignore those 23:48
but yeah now that i think about it maybe it is still movable
since the e.g. Makefiles wouldnt need to be ran again
23:48 sena_kun left
Voldenet I'd create an issue somewhere (in zef repo?) for either documenting that use case which is probably possible already 23:52
or implementing some simplified set up
tonyo envy should let you install to a directory you can inspect and find fairly easily, it works similarly to venv in python nemo (or to a centralized `node_modules` dir that you reference by name rather than `pwd`) 23:53
23:55 lichtkind 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!