Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec
Set by moderator on 6 October 2016.
01:48 ilbot3 joined
moderator Fire is step THREE! | github.com/perl6/toolchain-bikeshed | Channel logs: irclog.perlgeek.de/perl6-toolchain/today | useful prior art: metacpan.org/pod/CPAN::Meta::Spec
05:36 domidumont joined 05:41 domidumont joined 06:13 domidumont joined 06:19 domidumont joined
tbrowder hi, anyone awake 12:06
nine yep 12:07
[Coke] nope 12:08
tbrowder I just put my new module into the modules list and notice all (at least the last on the list) have the url to the master branch. Shouldn't the url be to a specific commit? 12:09
[Coke] modules ecosystem doesn't really deal with that well yet.
IIRC
I think most things are pointing to maste,r aye.
nine That's sooo much in need of attention 12:10
tbrowder can i help?
maybe just experiment with the url? 12:12
bye 12:16
12:16 tbrowder left 12:25 tbrowder joined
ugexe git clone every repo, grep for changes to meta.json "version" field incrementing, create duplicate meta but replacing source-url with whatever points at that commit 14:16
14:22 hoelzro joined, ugexe joined 14:57 FROGGS joined
tbrowder .tell ugexe sounds good, i think that code is in the perl6/ecosystem repo? 15:15
16:36 domidumont joined 16:40 domidumont joined
tbrowder no, modules... 16:44
ugexe you have to clone them yourself 16:59
and determien which commits point to which versions yourself
18:57 Cheery_ joined, tony-o joined, b2gills joined 19:00 ribasushi joined 19:08 Cheery joined, hoelzro joined, llfourn joined 19:19 TimToady joined, ugexe joined, lizmat joined 19:30 tbrowder joined 19:33 stevieb joined 19:34 stmuk_ joined 19:47 nine joined, mst joined, DrForr joined, sivoais joined 19:48 mst joined, pnu_ joined 20:07 sivoais joined 20:08 ranguard_ joined, jdv79_ joined 20:09 camelia joined
tbrowder what about adding an attribute in the META file pointing to the commit for a release? make it a requirement for entries in the ecosystem? 20:10
then the build tools should be able to do the right thing 20:11
moritz or we could, like, make actual releases 20:14
create tarballs and the likes
github isn't a CDN, and we should strive not to abuse it as one
tbrowder roger that! sounds like a good idea. and make some new conventions on providing appropriate references in the META file? 20:17
20:18 sivoais joined
tbrowder then use downloads instead of clones in the build tools? 20:18
moritz aye
I see two possible approaches 20:19
the first is to add each release to the ecosystem
the second is to provide another level of indirection
that is, the ecosystem has an URL to a file that lists all releases, including version name and URL 20:20
not a single META file for the whole distribution
ugexe you can already use downloads instead of clones if your source-url points at one
20:21 JimmyZ_ joined, moritz_ joined
tbrowder that sounds good to me. ecosys would, say, have latest release for everything but could pull a specific version if requested... 20:22
20:22 [Coke] joined, sjn joined
tbrowder but isn't that for travis at the moment? 20:23
if so, that would confuse development versions wouldn't it? 20:24
ugexe `zef --/p6c --/cached --cpan install "CSV::Parser:ver<1.*>"` downloads a .tar.gz from cpan if it exists
moritz_ tbrowder: I don't see the confusion. Care to elaborate? 20:26
tbrowder well, from the user perspective i expect the latest release from zef/panda by default; but from a dev working on a follow-on release i expect travis to use my master branch by default 20:28
moritz_ tbrowder: travis is under your control as a developer, so nothing stops you from using travis on your repo 20:29
tbrowder but that's what my confusion is: without som other conventions or some user-scripting, how do the two systems differentiate between an official release and a development branch? 20:31
don't they both use the meta file? 20:32
moritz_ tbrowder: for an official release, you as the author create a tarball, upload it to a hosting service of your choice, and add the version and URL to the meta file that's know to the ecosystem 20:33
tbrowder: this might be the meta file in your github repo, or a static file you put somewhere on the internet
tbrowder okay, but that doesn't work yet does it? 20:34
moritz_ it doesn't, right
that's what I thought your comment about extending the META file was about 20:35
ugexe how does that not work?
travis doesnt care what url you point your META at 20:36
moritz_ ugexe: how can I tell the ecosystem about multiple released versions right now?
20:38 pnu_ joined, nine joined, ribasushi joined
tbrowder at the moment it seems that the module list just points to the master branch and its existing meta info; unless i use a dev branch, then how are the two commits resolved? 20:39
20:39 DrForr joined, stevieb joined, TimToady joined, llfourn joined, b2gills joined, lizmat joined, tony-o joined, camelia joined, mst joined, stmuk_ joined
tbrowder moritz: that's right. i know we have lots of ways to work development but am currently constrained to stay off the master branch if i don't want to interfere with a release (if i understand all) 20:42
ugexe moritz_: link to specific meta.info file for each version you wish to release, with the source-url pointing at the proper location for that version 20:44
for instance: github.com/sergot/http-useragent/b.../META.info
however the latest version is 1.1.22
github.com/sergot/http-useragent/b.../META.info
moritz_ ugexe: so multile entries in the ecosystem? 20:45
ugexe i just mean its possible now, not that its a good solution
20:47 sivoais joined
moritz ugexe: yes, understood 20:50
IMHO it's a reasonable first step
like, if you have a new version of a p5 module, you also upload it to a central resource
which is analog to adding a new line to the ecosystem file 20:51
tbrowder ugexe: please explain, with the current module list format, how can that be done? 20:53
unless the build tools are modified; in that case, couldn't we just point to a tarball as moritz suggested? 20:57
ugexe above there are 2 links representing different versions of http::useragent. the source-url for each of these can point anywhere, including github .tar.gz releases 20:58
what i think you're asking for is something to just automatically guess the resource uri from a specific commit, and thats going to be different for different git providers as well as some people may want it to automatically link to git releases themselves 21:02
moritz no, I'm not asking for that 21:06
ugexe no you
not you
if you want to do this now you would 1) bump the version in your meta 2) push to github 3) cut a release 4) update the meta with the github release .tar.gz url 5) add your github.com/user/repo/blob/afjalfkj3...META6.json to the ecosystem list 21:08
tbrowder ugex: nor am i. i agreed with moritz, just think that docs and rules will need to specify the desired links and maybe other conventions--not too onerous. 21:09
ugexe: to be clear, if i do just as you say the tools do not need to change, i can do that now? 21:10
ugexe tbrowder: correct. panda wont but zef will, because panda can only clone git repos (not fetch over http or extract archives) 21:11
tbrowder um, sorry i type without reading yr words... 21:12
ugexe: okay, next question: whose zef, the user or the module server? 21:13
ugexe the user 21:14
tbrowder ugexe: that's probably a giant part of my misunderstanding: when i locally do a zef/panda update, what is happening? do both read the module list and update local data? 21:17
ugexe they both just download a single JSON file that contains the META info from all urls in the ecosystem 21:18
tbrowder given the recent survey isn't it time to retire panda? otherwise use of the tar ball references would confuse users during some interim period
or at least modify panda to say it doesn't recognize the format and tell the user to change to zef. 21:20
a
all right, i'm going to try the new method on my module! 21:22
ugexe gist.github.com/ugexe/1b3b83e5759d...b2b22013de This is an example of what the ecosystem would generate if you follow the steps above (it wont generate the _ecosystem-list-entry-url field tho, thats just what you would enter into th eecosystem list)
a CLI tool could be made to do all those steps fairly easily i would imagine 21:25
tbrowder ugexe: that's helpful--thank!
s/thank/thanks/

Powered by Cro and the Raku® Programming Language.

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

Thank you!