Re: New CPAN
On Sat, May 30, 2009 at 12:14:14PM -0600, David Green wrote: On 2009-May-30, at 12:06 pm, David Green wrote: ...what Perl6 is today, let alone what it will be tomorrow. Actually, we do kind of know what Perl will look like a decade from now, because P6 is deliberately extensible enough that we may never need a Perl 7. But that simply means that holiday photos are already a possibility: perl -MSteganography::Images pics/2009/ceylon.jpg In fact, you could do that in Perl 5 Storing things in PNGs has already been done, badly, by Acme::Steganography::Image::Png :-) Well, badly as far as the hiding bit goes. The effectiveness of the Floyd- Steinberg dithering actually surprised me. There's real software to do real steganography within JPEGs, that I think stated that it managed to use up to 1 bit in 9 without being obvious. I think that you'd have to understand the JPEG file format to make it work effectively, and I didn't need to do that to prove my point. (Which was that a photo sharing site with no file quota was not a good idea as it could be abused by third parties to completely externalise their file distribution costs) Mmm, I realise that this also means that I've had a JPEG file on CPAN for 4 years now, and no-one has commented :-) Nicholas Clark
Re: New CPAN
On Fri, 29 May 2009, Daniel Carrera wrote: Mark Overmeer wrote: And the next consideration: when we have a piece of software which administers Perl5 or Perl6 or Nokia.bin or Elf. Why stop there? What is the overlap? It is basically all just some blob of data with some associated meta-data to search and retreive the blobs. It is only the client side install tool which looks into the content of the package. Why not allow pure pod releases? A small step to documents in any other format. Why not share holiday pictures? Also just a blob of data with some meta-data. Your idea of using CPAN to share holiday pictures is one of the things that really turned me off from your CPAN6 proposal. I do want this to be about Perl, you don't, and that's a point where we differ. In my examples, Nokia.bin is so that mobile users don't have to compile software on their tiny CPUs. I can see merit in adding Ruby modules because in a new Parrot world, there is real opportunity for Perl and Ruby to share libraries with each other (e.g. Perl on Rails). But when you start talking about sharing holiday pictures, you have completely left the Perl realm and I am completely turned off. Allow me to point something out. He wants to write a freely available software package that can share data, and is useful for the Perl6 environment. He's not suggesting that we have holiday photos on CPAN-the-network, simply that the software not care whether the data inside it is a package or not, just whether it has metadata. If you don't like the holiday photos examples, just skim over them :). It's only 5 or so words to skip :). - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: New CPAN
* Andrew Whitworth (wknight8...@gmail.com) [090530 00:24]: I agree. Doing one thing well is so much better for everybody then doing a million things poorly. An assorted blob of data repository is far less valuable to the Perl5, Perl6, and Parrot communities then a dedicated library repository is. Why? Ever heart of extensible meta-data. Can be done in two ways. The idea is tha, on the three levels of implementation (see recent email in other thread), you have some meta-data. 1 On the CPAN6 level (transport layer) you have uniqueness information: give the release a name: . source archive URI or target name . product or package name . version and some standard data, like size and data of upload. 2 On the Pause6 level, you have adminstrative facts: . validation . access . searching, etc 3 On the application level (install tools etc) You may also need some facts. So: the core of the CPAN6 design is meta-data which accompany blocks. But I do not say that the Pause6 administration only accepts meta-data for level 1 and 2. It also transports meta-data on level 3. It does not UNDERSTAND that meta-data, but it does provide that meta-data. Ignoring information does not make the archives implementation harder. The ONLY difference between a specialized implementation of an archive and a flexible one like I propose, is that in the latter you are forced to clearly assign meta-data facts to one of these three levels. But there is no limitiation in the amount and content of the meta-data you can collect. Well, so your worries are unjustified. And the two simple solutions as I promissed in the first line of my comment: 1 Add three seperate meta-data fragments to one blob 2 Create one meta-data file which contains all three components. As simple as that. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: New CPAN
On Sat, May 30, 2009 at 7:56 AM, Mark Overmeer m...@overmeer.net wrote: * Andrew Whitworth (wknight8...@gmail.com) [090530 00:24]: I agree. Doing one thing well is so much better for everybody then doing a million things poorly. An assorted blob of data repository is far less valuable to the Perl5, Perl6, and Parrot communities then a dedicated library repository is. Why? Ever heart of extensible meta-data. Can be done in two ways. The idea is tha, on the three levels of implementation (see recent email in other thread), you have some meta-data. I'm not saying we *can't* create a general repository for all sorts of nonsense, I'm saying that we *shouldn't*. It doesn't matter what kind of meta data you use, or how you structure your URI, or whatever: It's a bad idea. In this case, we should follow the maxim that less is more, and realize that a tighter focus will create better value. People are going to form a one-to-one association with your project and what they expect to find there. When I think email, I immediately associate that in my mind with gmail. When I think encyclopedia, I make an immediate association to wikipedia, and vice versa. What do we want people to think about when they think about CPAN, dynamic software packages or all sorts of assorted garbage with extensible metadata. The ONLY difference between a specialized implementation of an archive and a flexible one like I propose, is that in the latter you are forced to clearly assign meta-data facts to one of these three levels. But there is no limitiation in the amount and content of the meta-data you can collect. If you want to create an infrastructure that is vastly extensible and too clever by half, that's you're prerogative. I don't care what software infrastructure we use for a new CPAN, nor what methodology is used to design it. What I do care about is that the final CPAN website that we end up with only contains packages related to Perl5, Perl6, and Parrot. Create a server that can theoretically handle images and other garbage if you want to, but we should make sure the site administrators disable that feature immediately. Well, so your worries are unjustified. And the two simple solutions as I promissed in the first line of my comment: 1 Add three seperate meta-data fragments to one blob 2 Create one meta-data file which contains all three components. As simple as that. Again, we are capable of doing this from a technical standpoint. It's still a bad idea. --Andrew Whitworth
Is the Perl community just about Code? (Was: Re: New CPAN)
Em Sex, 2009-05-29 às 23:37 +0200, Daniel Carrera escreveu: Your idea of using CPAN to share holiday pictures is one of the things that really turned me off from your CPAN6 proposal. If you replace holiday pictures by 'YAPC pictures', 'Talk slides', 'Code Snippets', 'Perl related scientific articles' it does look much more closer to a very good use of CPAN. A few days ago I posted[1] on Perlmonks about how we could extend the tools our community uses to get it even closer, and maybe this is one interesting answer to that. daniel [1] http://www.perlmonks.org/?node_id=765024
Re: New CPAN
On 2009-May-30, at 6:56 am, Andrew Whitworth wrote: I'm not saying we *can't* create a general repository for all sorts of nonsense, I'm saying that we *shouldn't*. Holiday photos is just a whimsical example. The problem is that it's hard enough keeping up with what Perl6 is today, let alone what it will be tomorrow. Or what Perl 7 will be, or what some other programming language/system will be that isn't even invented yet. Mark's point is that any arbitrary restrictions put in place now will seem short-sighted in 10 years' time, so we need something flexible. And it's all just 1s and 0s to the computer, so you *could* use it for photographs; that shouldn't matter to the software. If you want to create an infrastructure that is vastly extensible and too clever by half, that's you're prerogative. Sure, it's always possible to go too far. But on the other hand, isn't Perl 6 all about being too clever by half? It's certainly about being vastly extensible, anyway. -David
Re: New CPAN
On 2009-May-30, at 12:06 pm, David Green wrote: ...what Perl6 is today, let alone what it will be tomorrow. Actually, we do kind of know what Perl will look like a decade from now, because P6 is deliberately extensible enough that we may never need a Perl 7. But that simply means that holiday photos are already a possibility: perl -MSteganography::Images pics/2009/ceylon.jpg In fact, you could do that in Perl 5 On 2009-May-30, at 9:32 am, Daniel Ruoso wrote: If you replace holiday pictures by 'YAPC pictures', 'Talk slides', 'Code Snippets', 'Perl related scientific articles' it does look much more closer to a very good use of CPAN. Hm, all we need is the right grammar, and your slides can be their own code! -David
Re: New CPAN
* Daniel Carrera (daniel.carr...@theingots.org) [090528 16:07]: Mark Overmeer wrote: In March 2006, Sam Vilain and I started to think about a new CPAN what we named CPAN6. There is a lot of information about the project on http://cpan6.org I know about CPAN6, thanks. It's come up a couple of times on IRC. Perhaps you could hang out on the IRC channel so we don't have different people going off in different directions with CPAN. It's not a discussion like let's make a change to the current set-up, so IRC doesn't seem to me a good spot to discuss it. I gave various talks on YAPC's and interviewd a few of the CPAN maintainers. Workshops, Hackathons and YAPCs are more suitable. Trying to keep-up with normal email is already a daily struggle. Besides, having 9 hours time-difference with the West Coast doesn't help: when they wake-up at 8, I am just getting my 2 yr old son from Kindergarten back home. And when he finally sleeps, I am tired ;-) A) Can we add version, target flags to CPAN metadata? I was thinking that current modules would all be version=1 and target=perl5. CPAN does not have an official concept of version numbers on distributions, but only on the pm files which are inside the distribution. I know, thanks. I was suggesting a change. I had a discussion of two days about versions with Sam Vilain. What we came up with, is that there is only one solution: versions need to be strings without meaning. Of course, you can help yourself using some kind of logic sequencing these strings, but everyone has different ideas about how to do that. Who (besides Perl people) expect 5.10 after 5.8? The solution is simple: each release has a unique version string. The release also lists as meta-data what kind of follow-up it is to which existing release. For instance: 5.10.0 diverts from 5.8.8 (upgrade) 5.8.9replaces 5.8.8 (update) 5.10.1-blead diverts from 5.10.0 (devel) 5.10.1 replaces 5.10.0 and 5.10.1-blead (merge) In upgrade paths, replacements are safe upgrades and diversion may break code interfaces, where upgrades need more care (and probably explicit user approval) Which this approach, you can safely create all the weird versioning needs that Perl6 has designed. A picture could be presented to the users, to help making choices: | 5.8.8 | \ | \ 5.8.9 5.10.0 | \ | \ |5.10.1-blead | / 5.10.1 D) In addition to target=perl5 and target=perl6 we could have target=parrot. IMO, we need many more. What you call target is actually a namespace. The current CPAN archive has only one target. Target, namespace, same difference. It's an identifier to divide modules into categories. Well... do you need all archives to share one infrastructure? I think it is nicer to have people being able to open-up CPAN-like archives with additional features. For instance, if someone wants to publish pre-compiled PIR versions of modules, then s/he should not need the assistence of the core CPAN. With an URI namespace, you address an archive where you can find the data. A part of that namespace (URI fragment) could be a target within the archive. F) In summary, we have a possible course of action: There is a lot more structurally problematic. Please read one of my papers on the cpan6.org website. I have scanned through the first one. It's 30 pages... Oh, that's the small one. -- MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: New CPAN
Mark Overmeer wrote: I know about CPAN6, thanks. It's come up a couple of times on IRC. Perhaps you could hang out on the IRC channel so we don't have different people going off in different directions with CPAN. It's not a discussion like let's make a change to the current set-up, so IRC doesn't seem to me a good spot to discuss it. Nonetheless, IRC seems to be the place where discussion does happen. IRC has pros and cons over email. If you want to convince people to make the new CPAN the way you want, you have to join the conversation wherever it takes place. Workshops, Hackathons and YAPCs are more suitable. But those venues are not available on a day-to-day basis. Trying to keep-up with normal email is already a daily struggle. Besides, having 9 hours time-difference with the West Coast doesn't help: I have a 9-hour difference with the US West Coast. I suspect that I am in the same timezone as you. In addition, wayland76 is in Australia, and that's a 7h time difference between him and me. But somehow it works. I had a discussion of two days about versions with Sam Vilain. What we came up with, is that there is only one solution: Where did that discussion happen? Here? Could you send me the link to the right page on the list archives? F) In summary, we have a possible course of action: There is a lot more structurally problematic. Please read one of my papers on the cpan6.org website. I have scanned through the first one. It's 30 pages... Oh, that's the small one. In that case, I don't think I have time to read your papers. I'm sorry. I have other work to do. One other problem with a long paper is that it is not a conversation. It is a one-way communication medium, so it is less likely to build consensus (unless the paper itself was written through a consensus process). Daniel.
Re: New CPAN
* Daniel Carrera (daniel.carr...@theingots.org) [090529 08:17]: Workshops, Hackathons and YAPCs are more suitable. But those venues are not available on a day-to-day basis. At least, you get the time to discuss it in depth. Some even basic meta- data issues are just too complex for the short size of email, let alone IRC. Will you be at YAPC::EU in Lisbon? Let's BoF. I had a discussion of two days about versions with Sam Vilain. What we came up with, is that there is only one solution: Where did that discussion happen? Here? Could you send me the link to the right page on the list archives? He (from NZ) stayed at my place (in NL) for a few days before YAPC::EU 2007 (UK) where we gave a presentation about the subject. The results are in the initial paper page 22-24 http://www.cpan6.org/papers/cpan6-design.pdf A lot of the content of that design paper comes from discussions with many, many people. Oh, that's the small one. In that case, I don't think I have time to read your papers. I'm sorry. I have other work to do. Reading a paper is much less work than following IRC. When the brain- storm on IRC is over, someone will have to structurize the ideas into pages with comparible size and complexity. One other problem with a long paper is that it is not a conversation. It is a one-way communication medium, so it is less likely to build consensus (unless the paper itself was written through a consensus process). The paper describes many small components which need to be addressed, with limited detail. Of course, most is open for discussion. Most did have a lot of discussion already before it was written down. IMO, it never happens that things get implemented as described in the initial design. So, there is so much what can be changed when people come up with better plans. But nothing in there is about Perl6 installation tools or Linux Distribution packaging, where most of the discussion seems to be about. The overlap is meta-data definition and data transport. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: New CPAN
Mark Overmeer wrote: * Daniel Carrera (daniel.carr...@theingots.org) [090529 08:17]: Workshops, Hackathons and YAPCs are more suitable. But those venues are not available on a day-to-day basis. At least, you get the time to discuss it in depth. Some even basic meta- data issues are just too complex for the short size of email, let alone IRC. It'll have to be, because that's what we have. Hackathons and YAPCs don't happen that regularly. Hackathons and YAPCs are immensely valuable venues and they are far more efficient than email and IRC. But most of the time, email and IRC is all you have. Will you be at YAPC::EU in Lisbon? Let's BoF. No. I will be in my honey-moon. I'm getting married in July. My wife would kill me if I took her to YAPC for our honey moon :-) I had a discussion of two days about versions with Sam Vilain. What we came up with, is that there is only one solution: Where did that discussion happen? Here? Could you send me the link to the right page on the list archives? He (from NZ) stayed at my place (in NL) for a few days before YAPC::EU 2007 (UK) where we gave a presentation about the subject. The results are in the initial paper page 22-24 The discussion did not happen on this mailing list? Was it just you and Sam? I was hoping to see the discussion thread (rather than just this is what we decided). Reading a paper is much less work than following IRC. When the brain- storm on IRC is over, someone will have to structurize the ideas into pages with comparible size and complexity. I'm sorry, but I am not going to read your 30-page paper. Even the Synopses are not that long, and I can be fairly confident that the Synopses are the product of community consensus, so at least I have a good reason to read those. Daniel.
Re: New CPAN
* Daniel Carrera (daniel.carr...@theingots.org) [090529 09:38]: He (from NZ) stayed at my place (in NL) for a few days before YAPC::EU 2007 (UK) where we gave a presentation about the subject. The results are in the initial paper page 22-24 The discussion did not happen on this mailing list? Was it just you and Sam? I was hoping to see the discussion thread (rather than just this is what we decided). Two days of personal discussion is more than just an email thread. And decided is too strong: for well-thought reasons it went into the design this way. Until someone has a better idea with good arguments. Reading a paper is much less work than following IRC. When the brain- storm on IRC is over, someone will have to structurize the ideas into pages with comparible size and complexity. I'm sorry, but I am not going to read your 30-page paper. Even the Synopses are not that long, and I can be fairly confident that the Synopses are the product of community consensus, so at least I have a good reason to read those. Do not be blind folded by the formatting. A PDF of 30 pages with a few images easily looks larger than a plain text POD file. For instance, S02-bits.pod (the first real Synopsis) has 24078 words on 3790 lines. My plain-text TeX files have 11229 words on 1764... so the whole CPAN6 project is described in less than half the size of one Synopsis chapter. Synopses where written by Larry, of course after discussions but mainly based on his great personal design capabilities. And then polished further and further by the community. I do not see a difference with my approach... other than that there is not yet a community. Congratulated in advance with your marriage, next month. Of course, we can meet at some other moment because you live close-by. Or you can join the long list of people who guess that they understand what the CPAN6 project proposes and comment on that weak assumption. Anyone interested in a CPAN6 hackathon? -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: New CPAN
On Fri, 29 May 2009, Mark Overmeer wrote: * Daniel Carrera (daniel.carr...@theingots.org) [090528 16:07]: Mark Overmeer wrote: In March 2006, Sam Vilain and I started to think about a new CPAN what we named CPAN6. There is a lot of information about the project on http://cpan6.org I know about CPAN6, thanks. It's come up a couple of times on IRC. Perhaps you could hang out on the IRC channel so we don't have different people going off in different directions with CPAN. It's not a discussion like let's make a change to the current set-up, so IRC doesn't seem to me a good spot to discuss it. I gave various talks on YAPC's and interviewd a few of the CPAN maintainers. Workshops, Hackathons and YAPCs are more suitable. I support Daniel in that you should expect to miss things if you don't hang out on IRC. But I support Mark in the idea of longer formats, although I think 30 pages is a bit long. I've skimmed the document, though, enough to know what I need to know at the moment, I think (please correct me if I'm wrong). I'd like to suggest to Mark and Daniel that, seeing as I won't be making it to any Perl event outside Australia, and maybe not even some inside, and Mark can't keep up with IRC (my sympathies there), that the best place for such a discussion might be a mailing list such as p6l! (No sarcasm intended -- I'm saying you're doing the right thing, keep it up :) ). Trying to keep-up with normal email is already a daily struggle. Besides, having 9 hours time-difference with the West Coast doesn't help: when they wake-up at 8, I am just getting my 2 yr old son from Kindergarten back home. And when he finally sleeps, I am tired ;-) Mark: There's usually someone awake somewhere, even if it's only me here in Australia. DanielC: Don't argue with his time management until you have children. I don't, either, but I can see what a time-sink a family would be (even good things have their downsides). A) Can we add version, target flags to CPAN metadata? I was thinking that current modules would all be version=1 and target=perl5. CPAN does not have an official concept of version numbers on distributions, but only on the pm files which are inside the distribution. I know, thanks. I was suggesting a change. I had a discussion of two days about versions with Sam Vilain. What we came up with, is that there is only one solution: versions need to be strings without meaning. Of course, you can help yourself using some kind of logic sequencing these strings, but everyone has different ideas about how to do that. Who (besides Perl people) expect 5.10 after 5.8? Err, lots of people? The Linux kernel does its versions this way, so most people in the Open Source world are familiar with it. RPM seems to be able to handle things just fine, too. Example: kernel-2.6.27.5-117.local.fc10.i686 Version = 2.6.27.5 Release = 117.local The Version can be split up on the dots, and each compared numerically if available, and as strings if there are non-numerics. Allow me to point out that all the package managers out there have solved this problem, so it must be solveable. The solution is simple: each release has a unique version string. The release also lists as meta-data what kind of follow-up it is to which existing release. For instance: 5.10.0 diverts from 5.8.8 (upgrade) 5.8.9replaces 5.8.8 (update) 5.10.1-blead diverts from 5.10.0 (devel) 5.10.1 replaces 5.10.0 and 5.10.1-blead (merge) It may be useful to have these as recommendations, but I would hope that user policies and choices would be able to override them. D) In addition to target=perl5 and target=perl6 we could have target=parrot. IMO, we need many more. What you call target is actually a namespace. The current CPAN archive has only one target. Target, namespace, same difference. It's an identifier to divide modules into categories. Well... do you need all archives to share one infrastructure? I think it is nicer to have people being able to open-up CPAN-like archives with additional features. For instance, if someone wants to publish pre-compiled PIR versions of modules, then s/he should not need the assistence of the core CPAN. With an URI namespace, you address an archive where you can find the data. A part of that namespace (URI fragment) could be a target within the archive. While I've no objection to building the end-user software to support multiple repositories, I know that there are certain segments of the community who are very very keen to keep everything in the one repository. I'd agree with them, on the following conditions: - CPAN accepts packages in Perl5, Perl6, and anything else that runs on Parrot - Some of the other changes mentioned here get implemented (ie. Larry's idea of putting binary packages on CPAN as well) I have also been wondering about the idea of making CPAN a clearing
Re: New CPAN
Timothy S. Nelson wrote: While I've no objection to building the end-user software to support multiple repositories, I know that there are certain segments of the community who are very very keen to keep everything in the one repository. After reading the Zen of Comprehensive Archive Networks (ZCAN), I think there is very good reason for retaining the current infrastructure with the current, large, set of mirrors. That is not to say that we can't upgrade the packages and metadata. I'd agree with them, on the following conditions: -CPAN accepts packages in Perl5, Perl6, and anything else that runs on Parrot CPAN shall not piggyback another language -- from ZCAN. Judging from the ZCAN page, I don't expect that uploading Ruby modules to CPAN will go well, even if that module can be compiled to Parrot. The ZCAN page gave good reasons for this. -Some of the other changes mentioned here get implemented (ie. Larry's idea of putting binary packages on CPAN as well) I personally don't care. But some mirrors might object to having their disk usage go up 5-fold because we decided to include binaries for many operating systems and CPUs. The big problem with the multiple repos idea is that, unless each has a large organisation behind it, they die (witness the DAG RPM repo, which seemed deadish last time I looked; the packages are still there, but no updates seemed to be being made). CPAN, because it has a large enough organisation behind it, has a number of people behind it empowered with keeping it going. People don't want to have to keep up with the fashionable repos. +1 Daniel.
Re: New CPAN
On Fri, 29 May 2009, Daniel Carrera wrote: Timothy S. Nelson wrote: While I've no objection to building the end-user software to support multiple repositories, I know that there are certain segments of the community who are very very keen to keep everything in the one repository. After reading the Zen of Comprehensive Archive Networks (ZCAN), I think there is very good reason for retaining the current infrastructure with the current, large, set of mirrors. That is not to say that we can't upgrade the packages and metadata. Agreed. I'd agree with them, on the following conditions: -CPAN accepts packages in Perl5, Perl6, and anything else that runs on Parrot CPAN shall not piggyback another language -- from ZCAN. Judging from the ZCAN page, I don't expect that uploading Ruby modules to CPAN will go well, even if that module can be compiled to Parrot. The ZCAN page gave good reasons for this. I didn't find them compelling, myself. Because it's possible to call the Ruby modules from Perl6 now, if they're compiled on Parrot, it may be worth thinking about. -Some of the other changes mentioned here get implemented (ie. Larry's idea of putting binary packages on CPAN as well) I personally don't care. But some mirrors might object to having their disk usage go up 5-fold because we decided to include binaries for many operating systems and CPUs. I agree that's a problem. However, the recent suggestion of multiple repos on CPAN for the different OSs has given me an idea; make it possible to mirror CPAN for a certain set of architectures, ie. Source only (this is the default), Fedora, Debian, Nokia, etc. HTH, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: New CPAN
* Timothy S. Nelson (wayl...@wayland.id.au) [090529 11:26]: I'd like to suggest to Mark and Daniel that, seeing as I won't be making it to any Perl event outside Australia, and maybe not even some inside, and Mark can't keep up with IRC (my sympathies there), that the best place for such a discussion might be a mailing list such as p6l! (No sarcasm intended -- I'm saying you're doing the right thing, keep it up :) ). Once some people want to spend time on details of the subject, I suggest to revive a separate mailinglist for it. The list which we started two years back was never used. Installation/distribution is a complex matter with many aspects to be discussed, so deserves its own list simply not to bother the (quite independent subject of) Perl6. Who (besides Perl people) expect 5.10 after 5.8? Err, lots of people? kernel-2.6.27.5-117.local.fc10.i686 Eh, yes of course. That problem is only inside perl programs, where version numbers are considered floating point numbers. Where 5.8.8 == 5.008008 == 5.008_008. And then you have test versions like 68.17_02, which are broken floats and therefore flagged as development versions. In general, there are many versioning schemes which do often look alike, but do have subtile differences. Allow me to point out that all the package managers out there have solved this problem, so it must be solveable. Yes... but that also means that for some packaged products, versions need to get translated into a different versioning scheme. While I've no objection to building the end-user software to support multiple repositories, I know that there are certain segments of the community who are very very keen to keep everything in the one repository. I would like to add . cpants information . cpan-tester reports . code-only extracts# for small systems to install Perl . pod-only extracts # to add to code-only systems on demand . tests-only extracts . deb packages . rpm packages . pieton distributions . etc Oh, and then without name-space conflicts. And maintained by a small set of people. One of the main problems with the current set-up is the very limited pre-information about the installation available to CPAN.pm. It downloads a 02packages.details file which does not contain info about dependencies and such. One of the much heart complaints from normal Perl users is about the flood of unpredictable changes in the system once you install one module. Linux Distributions do also install many packages with one change, but are able to present that far more cleanly. Simply because they have more information at the start. What you probably need: dependencies, package size, licenses used, supported platforms, short description. An other consideration is the size of the 02packages file. This is now 750kB. It now lists only the last versions of each of the packages (not distribution!) in CPAN. But, when Perl6 introduces parallel versions, you may have people who actually want to use that feature. Business people other want an explicit module version, not the newest one. This means that the size of the 02packages files explodes with N times avg.nr.versions times number.of.targets times useful.additional.metadata My internet connection is very fast. Yours probably as well. We don't care about this, do we? The big problem with the multiple repos idea is that, unless each has a large organisation behind it, they die (witness the DAG RPM repo, which seemed deadish last time I looked; the packages are still there, but no updates seemed to be being made). Most projects die. The only reason why CPAN hasn't died is because of enormous effort by Andreas and a small group of other people. When Andreas is overrun by a Berlin bike, we have a serious problem. It is hard to find dedicated maintainers, as many Open Source projects have found out. IMO, fragmentation is crucial: you can not stack the load on a small group of dedicated people because they burn-up that way. People must be able to fork their own pet project, like search.cpan.org. And yes, that enlarges the chance that such a project dies. But that's normal evolution. At least, you have dedicated people with a work-load of their own choice. Considering above, I changed the concept of CPAN from a special thing for Perl5 only, into: collecting information is a basic need for groups of people. People start together an archive (collection) with a certain purpose. They lay-down the rules of that archive (who has super-user rights, permitted licenses, etc). And then, they have a standard implementation for collection needs: mirroring, versioning, various up- and download protocols, release under embargo, ..etc. A lot of maintenance effort by the current CPAN maintainers will not be needed anymore. Maintainers can focus on the quality of the content. Perl6, Perl5, parrot, pieton, python, PHP, family pictures, business
Re: New CPAN
* Daniel Carrera (daniel.carr...@theingots.org) [090529 11:42]: Timothy S. Nelson wrote: While I've no objection to building the end-user software to support multiple repositories, I know that there are certain segments of the community who are very very keen to keep everything in the one repository. After reading the Zen of Comprehensive Archive Networks (ZCAN), I think there is very good reason for retaining the current infrastructure with the current, large, set of mirrors. That is not to say that we can't upgrade the packages and metadata. It also says: Another important credo is: Avoid bottlenecks and interdependencies. Decentralize. Create and encourage alternatives. When reading the ZCAN, be very aware that it discusses CPAN. As users of CPAN, we all know that it works (for the moment). But that should never be a reason the think outside that box of daily practice! When making a step in development, first figure out which components of CPAN are really valuable, which are outdated, and which are missing. Then keep the good, salvage the outdated and fill-in the missing. Just to give you something to think of: with the current speed of networks and price of hardware, you do not need a huge network of daily synchronizing mirrors but a sufficiently large network of very up-to-date mirrors. Preferrably smart mirrors, which can answer (Ajax-like) some simple questions about distributions, such that you do not have to download the immensely growing 02packages.details files anymore. Ftp-mirror sync trees. If you add subtrees on your disk which contain different archives or targets, then these will get mirrored as well. CPAN shall not piggyback another language -- from ZCAN. Judging from the ZCAN page, I don't expect that uploading Ruby modules to CPAN will go well, even if that module can be compiled to Parrot. The ZCAN page gave good reasons for this. Agreed: do not merge sets of unrelated data! Perl6 and Perl5 are unrelated sets of data. The only relation is the people who use it. -- MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: New CPAN
* Nicholas Clark (n...@ccl4.org) [090529 14:07]: On Fri, May 29, 2009 at 02:43:13PM +0200, Mark Overmeer wrote: CPAN shall not piggyback another language -- from ZCAN. Judging from the ZCAN page, I don't expect that uploading Ruby modules to CPAN will go well, even if that module can be compiled to Parrot. The ZCAN page gave good reasons for this. Agreed: do not merge sets of unrelated data! Perl6 and Perl5 are unrelated sets of data. The only relation is the people who use it. I disagree. Strongly. ;-) CPAN is the Comprehensive Perl Archive Network. Not the Comprehensive Perl 5 Archive Network. What's in a name. Is it also CPAN is the Comprehensive Parrot Archive Network CPAN is the Comprehensive Pieton Archive Network CPAN is the Comprehensive Pony Archive Network CPAN is the Comprehensive PHPArchive Network CPAN is the Comprehensive PRuby Archive Network So, where do you stop? Perl6 and Perl5 have some things in common, just like PHP and Perl5. Some people say that Perl6 is a different language, not a next generation of Perl5. Do we need to install Perl5 on our system to get access to the install tools to install Perl6 modules? -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: New CPAN
Nicholas Clark wrote: On Fri, May 29, 2009 at 02:43:13PM +0200, Mark Overmeer wrote: * Daniel Carrera (daniel.carr...@theingots.org) [090529 11:42]: CPAN shall not piggyback another language -- from ZCAN. Judging from the ZCAN page, I don't expect that uploading Ruby modules to CPAN will go well, even if that module can be compiled to Parrot. The ZCAN page gave good reasons for this. Agreed: do not merge sets of unrelated data! Perl6 and Perl5 are unrelated sets of data. The only relation is the people who use it. I disagree. Strongly. CPAN is the Comprehensive Perl Archive Network. Not the Comprehensive Perl 5 Archive Network. I agree with Nicholas. I disagree with Mark. Though Mark may have replied to my comment with the word Agreed, I never said that we should separate Perl 5 and Perl 6!!! That is Mark's idea, not mine. As Nicholas says, CPAN is the Comprehensive *Perl* (not Perl 5) Archive Network. The example in my email was *Ruby*. Ruby is not Perl. But Perl 6 is Perl. I think that it would be a good idea to put Perl 5 and Perl 6 modules in the same CPAN. Not only do I not want to fragment CPAN, but for at least several years Perl 6 programs will depend heavily on Perl 5 modules. So all those Perl 5 modules up there in CPAN right now are going to be the first Perl 6 modules (via use v5). Daniel.
Re: New CPAN
* Daniel Carrera (daniel.carr...@theingots.org) [090529 14:24]: I think that it would be a good idea to put Perl 5 and Perl 6 modules in the same CPAN. I have a very cowardous reply on this. My CPAN6 design supports both sub-setting and super-setting archives. So, it can produce three access-points: pure-perl6, pure-perl5 and combined. If they physically share a disk store, you even do not even need copies of the releases. And... I do not really care what kind of information people keep inside the archive. That is for the founding board of the archive to decide. As long as it has meta-data, it is ok to my scope. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: New CPAN
Mark Overmeer wrote: CPAN is the Comprehensive Perl Archive Network. Not the Comprehensive Perl 5 Archive Network. What's in a name. Much, actually. As the ZCAN document explains, the set of mirrors are donated to Perl by various donors who agreed to hold *Perl* modules. These computers do not belong to us. If the donors agreed to hold Perl modules, it would be an abuse to use it to upload Ruby and Python modules as well. It is perfectly reasonable to put Perl 6 in CPAN. Perl 6 is Perl. It is defensible to put Parrot assembly in CPAN. But it is not ok to use a computer that was donated for Perl to also distribute Java, Ruby, PHP, Lua and Smalltalk modules. So, where do you stop? You stop at the point where you start breaching your verbal agreement with the owners of the computers you are using. Perl6 and Perl5 have some things in common, just like PHP and Perl5. Perl 6 is the next version of Perl 5 and Perl 6 comes with a Perl 5 compatibility mode and Perl 6 is intended to be able to use Perl 5 modules. That makes Perl 5 different from PHP. Daniel.
Re: New CPAN
* Daniel Carrera (daniel.carr...@theingots.org) [090529 14:39]: Much, actually. As the ZCAN document explains, the set of mirrors are donated to Perl by various donors who agreed to hold *Perl* modules. These computers do not belong to us. If the donors agreed to hold Perl modules, it would be an abuse to use it to upload Ruby and Python modules as well. Actually, there are various kinds of ftp-servers. Some are huge: they really don't care. Other are small: companies who use Perl and have made some diskspace available. They like to have a copy, and use it also for there own local installations. With Perl6 and other derivates, with the new version needs, the size of the archive will grow with factors. The current CPAN is tiny (fits on your photo-camera) The big guys really don't care about diskspace. The smaller may say: I am not using Perl6, so I don't want this 50GB on my ftp server. I would like to host Perl5, not Perl6/Parrot. Should we care to lose some ftp-mirrors? Ah, no, not really. Technology improvements made this a non-issue. One nicely connected ftp-server per continent may very well be sufficient now-adays. So, where do you stop? You stop at the point where you start breaching your verbal agreement with the owners of the computers you are using. I don't know: did they agree on Perl or Perl5? That's unclear. And will resolve itself some way or the other when either solution gets implemented. Perl6 and Perl5 have some things in common, just like PHP and Perl5. Perl 6 is the next version of Perl 5 and Perl 6 comes with a Perl 5 compatibility mode and Perl 6 is intended to be able to use Perl 5 modules. That makes Perl 5 different from PHP. The parrot-based PHP implementation will be able to link Perl6 and PHP code, if I understand correctly. And the same for Python. And Lua. and so on. I don't know. I am less convinced about a strong bond than you. Ok, enough stirring-up for today. Let's eat diner. -- MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: New CPAN
On Fri, May 29, 2009 at 04:23:56PM +0200, Mark Overmeer wrote: What's in a name. Is it also CPAN is the Comprehensive Parrot Archive Network CPAN is the Comprehensive Pieton Archive Network CPAN is the Comprehensive Pony Archive Network CPAN is the Comprehensive PHPArchive Network CPAN is the Comprehensive PRuby Archive Network So, where do you stop? Perl6 and Perl5 have some things in common, just like PHP and Perl5. Some people say that Perl6 is a different language, not a next generation of Perl5. With parrot supporting many scripting languages and making them accessible from perl, there is a huge value in having cpan.pm (whatever it ends up being called) providing transparent access to all of those and more - regardless of whether they are all in a single archive or (more likely) a network of archives, each providing some sub-set of the possibilities. Taking a valuable module written in another language and rewriting it in perl has been done many times in the past, but will be less necessary in the future. A perl6 sub-class of the original module will be a much easier task and often provide the specific addition that is required. Do we need to install Perl5 on our system to get access to the install tools to install Perl6 modules? Certainly we need to install Perl5 *modules* until they are *all* superceeded by Perl6 (or Ruby or Python) replacements.
Re: New CPAN
On Thu, May 28, 2009 at 11:07 AM, Daniel Carrera daniel.carr...@theingots.org wrote: Mark Overmeer wrote: The problem is more serious. Perl6 installation needs to have multiple versions of the same module installed in parallel (and even run within the same program!). Why? See http://perlcabal.org/syn/S11.html#Versioning -Scott -- Jonathan Scott Duff perlpi...@gmail.com
Re: New CPAN
On Fri, May 29, 2009 at 05:32:16PM +0200, Mark Overmeer wrote: : Perl6 and Perl5 have some things in common, just like PHP and Perl5. : : Perl 6 is the next version of Perl 5 and Perl 6 comes with a Perl 5 : compatibility mode and Perl 6 is intended to be able to use Perl 5 : modules. That makes Perl 5 different from PHP. : : The parrot-based PHP implementation will be able to link Perl6 and : PHP code, if I understand correctly. And the same for Python. And : Lua. and so on. I don't know. I am less convinced about a strong : bond than you. And indeed, Perl 6 considers all other languages to be dialects of itself. Even if you say Perl only, any Perl 6 program can say: use Befunge; and then continue in the Befunge dialect of Perl 6, assuming the Befunge Perl 6 module is available. :) I realize this is not the current attitude of (much of) the Perl 5 community, but originally Perl succeeded because it *connected* with everything else it could, not because it was trying to be an island to itself. Perl was never supposed to be about drawing boundaries. Larry
Re: New CPAN
On Fri, May 29, 2009 at 04:32:00PM +0200, Mark Overmeer wrote: : * Daniel Carrera (daniel.carr...@theingots.org) [090529 14:24]: : I think that it would be a good idea to put Perl 5 and Perl 6 modules in : the same CPAN. : : I have a very cowardous reply on this. My CPAN6 design supports both : sub-setting and super-setting archives. So, it can produce three : access-points: pure-perl6, pure-perl5 and combined. If they physically : share a disk store, you even do not even need copies of the releases. : : And... I do not really care what kind of information people keep inside : the archive. That is for the founding board of the archive to decide. : As long as it has meta-data, it is ok to my scope. I think this is an important point, philosophically. The internet, and later the web, both succeeded primarily because they unified identity *without* resorting to centralization (except to bootstrap the top-level nameservers, of course). But identity must not be confused with location. It's perfectly fine for various repos to store only a subset of an archive, just as it's perfectly fine for a node on the internet to only handle a portion of the traffic. But they get away with this only because of uniform addressing. So think of this as more a problem of identity. The data can flow wherever it likes, as in a p2p network; as long as you can actually *name* what you want to acquire, the network can figure out how to give it to you eventually. This is why S11 specs that module versions are immutable once made official, and names include versions and naming authorities (and presumably some checksumming), so that it doesn't matter where you get the module from, it will always be the same thing. Nothing else is likely to scale. Let's all remember the old joke: Biologist: What could possibly be worse than a velociraptor? Physicist: Obviously, an acceloraptor. Long term, acceloraptors tend to beat out velociraptors. Perl 6 is all about being an acceloraptor. :) Larry
Re: New CPAN
Larry Wall wrote: I think this is an important point, philosophically. The internet, and later the web, both succeeded primarily because they unified identity *without* resorting to centralization (except to bootstrap the top-level nameservers, of course). But identity must not be confused with location. It's perfectly fine for various repos to store only a subset of an archive, just as it's perfectly fine for a node on the internet to only handle a portion of the traffic. But they get away with this only because of uniform addressing. Indeed, there is no reason why every CPAN mirror has to hold *all* of CPAN. As long as the actual module-mirror resolution happens transparently, what does it matter? Following up on the points raised by Mark and Larry, a more distributed CPAN (where each mirror can choose *what* to mirror) could point the way to resolving both of the issues I've mentioned: 1) Mirrors who want to hold Perl but not (say) Ruby. 2) Mirrors who don't want to hold (say) binaries for the Nokia handheld. If mirrors can choose what parts of the CPAN repository they want to mirror, the above issues go away. If you don't want to mirror binaries in your server, you don't have to. As long as we use some URI/DNS type system, we can locate *some* mirror that has the module we are looking for, and just grab it from there. Taking the distributed idea further, mirrors could use some kind of P2P system in the style of Bittorrent in order to distribute new modules and updates throughout the CPAN network. What do you think? With these changes (letting mirrors choose what they want to mirror) I would guess that the only issues left with CPAN holding Ruby modules is philosophical. Personally I don't feel strongly about the philosophy. I would be quite happy to install a module I can use from Perl 6 even if it was written in Ruby (Perl on Rails anybody?). Btw, if the majority wants to start uploading Ruby, Python and Lua modules to CPAN, we can rename CPAN so that the P stands for something else that doesn't mean anything. Comprehensive Peacock Archive Network? Comprehensive Platypus Archive Network? Daniel.
Re: New CPAN
Daniel Carrera wrote: Btw, if the majority wants to start uploading Ruby, Python and Lua modules to CPAN, we can rename CPAN so that the P stands for something else that doesn't mean anything. Comprehensive Peacock Archive Network? Comprehensive Platypus Archive Network? my (@C,@P,@A,@N); @C = Comprehensively Conspicuously Continuously Completely Certainly; @P = Pathological Perplexing Powerful Pervasive Pedestrian Pure Posh; @A = Archive Array Anthology; @N = Network Nest; say (@C.pick,@P.pick,@A.pick,@N.pick).join( ); Cheers, Daniel.
Re: New CPAN
On Fri, May 29, 2009 at 07:26:11PM +0200, Daniel Carrera wrote: Btw, if the majority wants to start uploading Ruby, Python and Lua modules to CPAN, we can rename CPAN so that the P stands for something else that doesn't mean anything. Comprehensive Peacock Archive Network? Comprehensive Platypus Archive Network? Comprehensive Programming Archive Network. (I started with Pscripting, but decided that was too restrictive.)
[Fwd: Re: New CPAN]
Sorry, didn't do a reply-all on this. ---BeginMessage--- How about Parrot? I think the original point, along with one of the original claims for Parrot, was that Parrot would not just be the Perl internals engine but would be general enough to run other languages. (Specifically, there are Tcl, Python, Pascal, and Lua implementations in various stages of dress.) So if someone wrote the next killer thing (Rails, anyone?) in some language that compiles to Parrot, it should be possible to install the parrot binary and have it work if you're a Perl6/Parrot user instead of a Ruby/Parrot or C#/Parrot or Pascal/Parrot user. The risk is that there are now more Perl6es than just Rakudo. This tends to force language level instead of binary level distribution. It's sort of like the difference between CPAN and Maven. Maybe they're two different things. There's a use-case question there, which should probably be addressed by someone who has read the CPAN6 requirements doc (I have not). =Austin Daniel Carrera wrote: Daniel Carrera wrote: Btw, if the majority wants to start uploading Ruby, Python and Lua modules to CPAN, we can rename CPAN so that the P stands for something else that doesn't mean anything. Comprehensive Peacock Archive Network? Comprehensive Platypus Archive Network? my (@C,@P,@A,@N); @C = Comprehensively Conspicuously Continuously Completely Certainly; @P = Pathological Perplexing Powerful Pervasive Pedestrian Pure Posh; @A = Archive Array Anthology; @N = Network Nest; say (@C.pick,@P.pick,@A.pick,@N.pick).join( ); Cheers, Daniel. ---End Message---
Re: New CPAN
John Macdonald wrote: On Fri, May 29, 2009 at 07:26:11PM +0200, Daniel Carrera wrote: Btw, if the majority wants to start uploading Ruby, Python and Lua modules to CPAN, we can rename CPAN so that the P stands for something else that doesn't mean anything. Comprehensive Peacock Archive Network? Comprehensive Platypus Archive Network? Comprehensive Programming Archive Network. I thought of that, but it sounded very broad to me (e.g. assembly language, compiled binaries that can't be used b Perl, etc). In any case, if most people agree with the general principle of renaming CPAN, we can have a Condorcet vote. Condorcet is a method whereby you rank all the options in order of preference and Condorcet selects the compromise candidate. Unlike the antiquated voting system that most countries use, Condorcet does not suffer from split votes. Daniel.
Re: New CPAN
John Macdonald wrote: Comprehensive Programming Archive Network. Another problem with Programming is that it assumes that other languages will actually use the system. We don't know that currently and it is a bit presumptions to assume that they will. It would look awkward if only Perl used the Comprehensive Programming Archive Network. I think it's better to pick a name that doesn't assume very much in either direction and just see what happens. Btw, if we do go ahead with this meta CPAN idea, it'll be important to divide the network into self-contained groups. Earlier I used the word target. Alternatively we could say platform. Example platforms could include: Perl 5 -- Perl 5 source code. Perl 6 -- Perl 6 source code. Parrot -- Parrot assembly. Lua-- Lua source code. Nokia.bin -- Compiled binary for the Nokia handheld. Elf-ia64 -- Compiled binary in ELF format for the IA64 architecture. You get the idea... Mirrors pick which platforms they'll hold. Then we can say that if anyone wants to add a platform to CPAN, they have to find people willing to maintain it. In other words, the Perl guys will only maintain the Perl platforms. But the Lua guys are welcome to get people together and administer a Lua platform on CPAN. Just some ideas... Daniel.
Re: New CPAN
* Daniel Carrera (daniel.carr...@theingots.org) [090529 19:55]: Btw, if we do go ahead with this meta CPAN idea, it'll be important to divide the network into self-contained groups. Earlier I used the word target. Alternatively we could say platform. Example platforms could include: Perl 5 -- Perl 5 source code. Perl 6 -- Perl 6 source code. Parrot -- Parrot assembly. Lua-- Lua source code. Nokia.bin -- Compiled binary for the Nokia handheld. Elf-ia64 -- Compiled binary in ELF format for the IA64 architecture. You get the idea... Mirrors pick which platforms they'll hold. Now we are getting somewhere. A mirror doing only a part is a bit strange. A mirror doing half-work is more a filter. So, if we replace your term platform into my term archive, and your meta CPAN archive into my CPAN6, then we are on the same track... I call it CPAN6 servers invite selected archives on their system, where you like to say CPAN mirrors copy selected platforms/targets of the main archive And the next consideration: when we have a piece of software which administers Perl5 or Perl6 or Nokia.bin or Elf. Why stop there? What is the overlap? It is basically all just some blob of data with some associated meta-data to search and retreive the blobs. It is only the client side install tool which looks into the content of the package. Why not allow pure pod releases? A small step to documents in any other format. Why not share holiday pictures? Also just a blob of data with some meta-data. Those final steps changed my world. Where Windows has a My Pictures directory, how do we organize Our Pictures? Just a hack: Flickr or a shared NFS disk. And Our Software?: CPAN. And there are document management systems, ftp-servers, linux distributions, ... etc etc... And all facilitate creating collections of a certain type. People are collectors by evolution, for their own or for a group. It is simple to organize a private collection on computers, but for all group collections on computers, we only have hacks. Studying different kinds of collections have led me to a relatively small set of features we need. What will we share, with whom, how do we distribute, where do we store it what does it need additionally. Add some modern needs as security, fail-over and license tracking and see my meta-data design. The surprise is that I have not been able to find any software where you can start collections as general basic infrastructure. On the level of network file-system. A totally new application of Internet. The beauty of our community collection in CPAN can be extended to benefit all computer users. That is where my CPAN6 is about. CPAN to the power 6. Oh, maybe it will also be used for the Perl6 module collection. That's to the Perl people to decide. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: New CPAN
Mark Overmeer wrote: And the next consideration: when we have a piece of software which administers Perl5 or Perl6 or Nokia.bin or Elf. Why stop there? What is the overlap? It is basically all just some blob of data with some associated meta-data to search and retreive the blobs. It is only the client side install tool which looks into the content of the package. Why not allow pure pod releases? A small step to documents in any other format. Why not share holiday pictures? Also just a blob of data with some meta-data. Your idea of using CPAN to share holiday pictures is one of the things that really turned me off from your CPAN6 proposal. I do want this to be about Perl, you don't, and that's a point where we differ. In my examples, Nokia.bin is so that mobile users don't have to compile software on their tiny CPUs. I can see merit in adding Ruby modules because in a new Parrot world, there is real opportunity for Perl and Ruby to share libraries with each other (e.g. Perl on Rails). But when you start talking about sharing holiday pictures, you have completely left the Perl realm and I am completely turned off. Daniel.
Re: New CPAN
On Fri, May 29, 2009 at 5:37 PM, Daniel Carrera daniel.carr...@theingots.org wrote: Mark Overmeer wrote: And the next consideration: when we have a piece of software which administers Perl5 or Perl6 or Nokia.bin or Elf. Why stop there? What is the overlap? It is basically all just some blob of data with some associated meta-data to search and retreive the blobs. It is only the client side install tool which looks into the content of the package. Why not allow pure pod releases? A small step to documents in any other format. Why not share holiday pictures? Also just a blob of data with some meta-data. Your idea of using CPAN to share holiday pictures is one of the things that really turned me off from your CPAN6 proposal. I do want this to be about Perl, you don't, and that's a point where we differ. In my examples, Nokia.bin is so that mobile users don't have to compile software on their tiny CPUs. I can see merit in adding Ruby modules because in a new Parrot world, there is real opportunity for Perl and Ruby to share libraries with each other (e.g. Perl on Rails). But when you start talking about sharing holiday pictures, you have completely left the Perl realm and I am completely turned off. I agree. Doing one thing well is so much better for everybody then doing a million things poorly. An assorted blob of data repository is far less valuable to the Perl5, Perl6, and Parrot communities then a dedicated library repository is. Adding metadata to something like the existing CPAN that describes language and implementation is a step that allows Perl6 libraries and maybe even POD-only releases (language=pod, platform=pod) to be supported in the short term and opens the possibility of multiple languages being supported in the future. However, adding these two bits of metadata cannot be used meaningfully to allow all sorts of random media, which is a Good Thing. We want a future CPAN to be the place to go for supported and tested library packages for Perl and maybe other languages, not the place where people dump assorted unrelated shit. --Andrew Whitworth
Re: [Fwd: Re: New CPAN]
On Fri, 29 May 2009, Austin Hastings wrote: How about Parrot? Because the SMOP Perl 6 implementation doesn't target Parrot, and won't, and we want to include them too. Likewise other P6 implementations. HTH, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: New CPAN
Wayland wrote: Allow me to point something out. He wants to write a freely available software package that can share data, and is useful for the Perl6 environment. He's not suggesting that we have holiday photos on CPAN-the-network, I'm not sure about that. We were talking about what things to include in CPAN-the-network (the new hypothetical p2p one where mirrors can choose what they want to mirror). I say that we could possibly permit compiled Perl module binaries or Ruby modules that run on Parrot. Mark says why stop there? why not share holiday pictures?. simply that the software not care whether the data inside it is a package or not, just whether it has metadata. If you don't like the holiday photos examples, just skim over them :). It's only 5 or so words to skip :). It is not just 5 words to skip if those 5 words are the main point of his email (words are not created equal :) ). Daniel.
Re: New CPAN
On Fri, 29 May 2009, Mark Overmeer wrote: * Timothy S. Nelson (wayl...@wayland.id.au) [090529 11:26]: I'd like to suggest to Mark and Daniel that, seeing as I won't be making it to any Perl event outside Australia, and maybe not even some inside, and Mark can't keep up with IRC (my sympathies there), that the best place for such a discussion might be a mailing list such as p6l! (No sarcasm intended -- I'm saying you're doing the right thing, keep it up :) ). Once some people want to spend time on details of the subject, I suggest to revive a separate mailinglist for it. The list which we started two years back was never used. Installation/distribution is a complex matter with many aspects to be discussed, so deserves its own list simply not to bother the (quite independent subject of) Perl6. What's the mailing list called? And is it gone, or active-unused? Who (besides Perl people) expect 5.10 after 5.8? Err, lots of people? kernel-2.6.27.5-117.local.fc10.i686 Eh, yes of course. That problem is only inside perl programs, where version numbers are considered floating point numbers. Where 5.8.8 == 5.008008 == 5.008_008. And then you have test versions like 68.17_02, which are broken floats and therefore flagged as development versions. I believe Perl 6 explicitly supports a version type that handles some of this (I know that's not a general solution, but still...). Allow me to point out that all the package managers out there have solved this problem, so it must be solveable. Yes... but that also means that for some packaged products, versions need to get translated into a different versioning scheme. That may be the case, but it's probably the worry of Software::Packager. Hopefully we can make it cope. One of the main problems with the current set-up is the very limited pre-information about the installation available to CPAN.pm. It downloads a 02packages.details file which does not contain info about dependencies and such. One of the much heart complaints from normal Fixing this++ My internet connection is very fast. Yours probably as well. We don't care about this, do we? I do! :) IMO, fragmentation is crucial: you can not stack the load on a small group of dedicated people because they burn-up that way. People must be able to fork their own pet project, like search.cpan.org. And yes, that enlarges the chance that such a project dies. But that's normal evolution. At least, you have dedicated people with a work-load of their own choice. The thing is, CPAN is mirrored everywhere. If fragmentation occurs, some parts that are not mirrored may not be completely lost. I guess that's my fear. Anyway, I hope some of this helps. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: New CPAN
* Daniel Carrera (daniel.carr...@theingots.org) [090528 14:18]: There was some talk on IRC about a new version of CPAN to match the new version of Perl. In March 2006, Sam Vilain and I started to think about a new CPAN what we named CPAN6. There is a lot of information about the project on http://cpan6.org You can see there that a lot of work has been doen. Core Perl people did really discourage me by continuously debating about the name of the project, instead of helping to implement it. But now other people start to wake up, it might get back on track. Recap: wayland76 wants to integrate CPAN with the local package manager (RPM, DEB). He proposed using Software::Package for that (which is incomplete). Be aware that there are confusing entanglements in the current set-up. Firstly, you have the CPAN archive, which uses Pause as entry point and ftp-servers to distribute the accepted distributions. Secondly, you need local configuration tools to get distributions installed on the right spot. That differs per platform. And sometimes people install for instance under usernames, not system-wide. This is the playfield of CPAN.pm and CPANPLUS. For instance compiling XS, discovering libraries, ... Then, you have the administration on what is installed. Basically, that is what RPM/DEB packages think is interesting. CPAN6 is a possible alternative to the first (the CPAN archive), but improving on the second by allowing advanced (server side) searches. Perl's installation tools have a very limited knowledge... much less than search.cpan.org. A) Can we add version, target flags to CPAN metadata? I was thinking that current modules would all be version=1 and target=perl5. CPAN does not have an official concept of version numbers on distributions, but only on the pm files which are inside the distribution. The 02packages list which is used to lookup dependencies converts pm-file $VERSION into distribution names which accidentally contain a number. The problem is more serious. Perl6 installation needs to have multiple versions of the same module installed in parallel (and even run within the same program!). So the whole concept of installation has to change into something more modern. D) In addition to target=perl5 and target=perl6 we could have target=parrot. IMO, we need many more. What you call target is actually a namespace. The current CPAN archive has only one target. But with Perl6, we have a need for perl6 distributions, but also the pre-compiled versions of these modules, for PIR, pasm, pieton, and whatever languages we will develop based on Parrot. And... maybe deb and rpm archives which (semi-)automatically provide repackaged versions of modules which arrive in the perl6 archive. CPAN6 can do all that in a rather simple way. E) With all this done, we can talk about the new CPAN package format. We can use the alien utility (written in Perl) to finish the Software::Package distribution (which currently only supports RPM). CPAN6's opinion: it distributes releases (Perl5 terminologie: a distribution) which simply is a set of files. During transport, they may get packed together (with f.i. tar) and compressed (with f.i. gzip), but that is unimportant. Whether only a single file is shipped (like a single tar.gz prepared by the author) or many does not matter. So: a minimal installation tool does not need Archive::Tar and a zillion of other core modules in my design. F) In summary, we have a possible course of action: There is a lot more structurally problematic. Please read one of my papers on the cpan6.org website. I am looking forward to meet people who have read my design documents, and understand that there is more to it than let's discuss about the project name. There is at least 40k lines of Perl code already waiting to be used for this task. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
RFC: How does using CPAN with Perl 6 would look like (Was: Re: New CPAN)
Em Qui, 2009-05-28 às 16:18 +0200, Daniel Carrera escreveu: Hello all, There was some talk on IRC about a new version of CPAN to match the new version of Perl. I just wanted to point out some previous conclusion on this issue. What currently we generically name CPAN is actually composed of: 1 - A repository for source archives 2 - A build-system (ExtUtils::MAkeMaker, Module::Build) For Perl 6, there is already some kind of consensus that we need an architecture that goes in the following lines 1 - A repository for source archives (that's markov's CPAN6) 2 - An abstract representation for the source's metadata (describing what the archive has, instead of how to build and install) 3 - A per-implementation per-architecture infra-estructure that knows how to take this abstract metadata and build a installable package (for that implementation and architecture) 4 - A per-implementation per-architecture package manager (in some cases the native package manager can be used) that install and handles dependencies of installable packages. So, a regular scenario would look like: 1 - You search for something, find Some::Module and download Some-Module-0.1.tar.gz it from CPAN6 2 - Some-Module-0.1.tar.gz contains a META.yml like file containing a description of what composes this archive 3 - You run rakudo-build Some-Module-0.1.tar.gz if you're in rakudo or smop-build Some-Module-0.1.tar.gz if you're in smop. If you're in a Debian machine that should build libsome-module-parrot_0.1_i386.deb or libsome-module-smop_0.1_i386.deb. 4 - As in the Debian case, you would use the native package manager, you could simply apt-get install libsome-module-rakudo (considering the above step put the file in a local repo, as apt-build does today). If you're in Win32, a package manager is probably going to written so you can install the 'installable' package in a similar manner. daniel
Re: New CPAN
Mark Overmeer wrote: In March 2006, Sam Vilain and I started to think about a new CPAN what we named CPAN6. There is a lot of information about the project on http://cpan6.org I know about CPAN6, thanks. It's come up a couple of times on IRC. Perhaps you could hang out on the IRC channel so we don't have different people going off in different directions with CPAN. Core Perl people did really discourage me by continuously debating about the name of the project, instead of helping to implement it. I can see how this could be a point of contention. If I made a website called gimp3.org I'd expect some flack from the Gimp people. A) Can we add version, target flags to CPAN metadata? I was thinking that current modules would all be version=1 and target=perl5. CPAN does not have an official concept of version numbers on distributions, but only on the pm files which are inside the distribution. I know, thanks. I was suggesting a change. The problem is more serious. Perl6 installation needs to have multiple versions of the same module installed in parallel (and even run within the same program!). Why? D) In addition to target=perl5 and target=perl6 we could have target=parrot. IMO, we need many more. What you call target is actually a namespace. The current CPAN archive has only one target. Target, namespace, same difference. It's an identifier to divide modules into categories. F) In summary, we have a possible course of action: There is a lot more structurally problematic. Please read one of my papers on the cpan6.org website. I have scanned through the first one. It's 30 pages... Daniel.
Re: New CPAN
Jonathan Scott Duff wrote: See http://perlcabal.org/syn/S11.html#Versioning Yeah, I reached that part earlier today (but after I sent my email). Thanks. Daniel.
Re: New CPAN
Daniel Carrera wrote: Mark Overmeer wrote: The problem is more serious. Perl6 installation needs to have multiple versions of the same module installed in parallel (and even run within the same program!). Why? Because we need things to work effectively in the general case where what was originally a single module Foo with one name becomes forked with each creator (authority) going off in their own direction, or alternately the creator makes incompatible changes, and then later someone's project Bar may have a bunch of dependencies A and B where A depends on one version of Foo and B depends on an incompatible version of Foo; then both versions of Foo need to work together. And that's just one reason to have this support. -- Darren Duncan
Re: New CPAN
Darren Duncan wrote: Because we need things to work effectively in the general case where what was originally a single module Foo with one name becomes forked with each creator (authority) going off in their own direction, or alternately the creator makes incompatible changes, and then later someone's project Bar may have a bunch of dependencies A and B where A depends on one version of Foo and B depends on an incompatible version of Foo; then both versions of Foo need to work together. And that's just one reason to have this support. -- Darren Duncan Yeah. At the time I wrote that I hadn't yet read S11. The new CPAN needs to handle all the metadata in S11. use Whiteness:fromperl5 Acme::Bleach 1.12 cpan:DCONWAY; So we have to give some thought to how the modules are going to be stored in the system. Daniel. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
