Re: [Catalyst] Advent Calendar... Grant proposal...
I'm rather concerned with that statement, but will allow time for all of us to sober up. On 03/01/15 22:44, Lance A. Brown wrote: Robert Brown wrote on 1/3/2015 5:36 PM: Is this something we can resolve, or simply make better as its install process, that maybe needs explaining better? I don't think it can be resolved unless Catalyst wants to move in the same direction Mojolicious has taken, which I don't agree with. I hesitate to call it a warning, but some kind of note in the documentation and or at the beginning of the Catalyst install process to let the user know it will take some time would be useful. --[Lance] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
Installation is basically a one shot (especially if you have a transportable perl compiled with perlbrew of Perl::Build). A framework is for life not just for a 5 minute write a blog engine demo. On Sun, Jan 4, 2015 at 9:44 AM, Lance A. Brown la...@bearcircle.net wrote: Robert Brown wrote on 1/3/2015 5:36 PM: Is this something we can resolve, or simply make better as its install process, that maybe needs explaining better? I don't think it can be resolved unless Catalyst wants to move in the same direction Mojolicious has taken, which I don't agree with. I hesitate to call it a warning, but some kind of note in the documentation and or at the beginning of the Catalyst install process to let the user know it will take some time would be useful. --[Lance] -- GPG Fingerprint: 409B A409 A38D 92BF 15D9 6EEE 9A82 F2AC 69AC 07B9 CACert.org Assurer ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
But that really depends on the system, doesn't it? I can install the usual parts of Catalyst by installing just a few packages on a Debian (and Debian-derived) systems. It takes a few minutes (less than ten, surely), but it's an easy process. Isn't that the primary purpose of distribution packaging teams? Assembling the various parts into a whole that is easily installed? On 01/03/2015 11:44 PM, Lance A. Brown wrote: Robert Brown wrote on 1/3/2015 5:36 PM: Is this something we can resolve, or simply make better as its install process, that maybe needs explaining better? I don't think it can be resolved unless Catalyst wants to move in the same direction Mojolicious has taken, which I don't agree with. I hesitate to call it a warning, but some kind of note in the documentation and or at the beginning of the Catalyst install process to let the user know it will take some time would be useful. --[Lance] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
I think that one of the main use of Perl is to create web apps. And the best way of creating web apps is by using a web framework. And the most developed web framework for Perl is Catalyst. But those who prefer other frameworks do it because they consider Catalyst too complex and hard to understand. So yes, a more clear documentation for Catalyst should be very helpful. Newbies might have the time and willing to write it, but they might not know what to write. :) So... applying for a grant to do it may be the solution. --Octavian Good documentation is clearly necessary, but I don't think that it will by itself be enough to attract newbies. I am an interested newbie, so perhaps I can add something to the conversation. My impression is that Catalyst is not so complex by itself, but it sits at the top of a pyramid of knowledge domains that are both broad and deep. MVC (each letter is a book in itself), Perl/CPAN, OO, web servers, security, web hosting (your shared hosting won't work), etc. What did I miss? The loosely coupled Catalyst approach to web frameworks therefore benefits from a loosely coupled approach to Catalyst training. What's the minimum required knowledge to create a best practice web application using Catalyst? Each area requires a loosely coupled learning module, that both stands on its own, and directly supports a minimal, yet best practice prerequisite understanding necessary for integration into a Catalyst application. I'd like to point out Andrew Solomon's excellent Geekuni courses. I'm just finishing up the Perl Essentials course, which I enrolled in primarily as an on-ramp to the Dancer course. The combination of carefully designed tasks, instant feedback, and mentoring provides a holistic learning experience that I couldn't achieve from months of reading books, online tutorials, and writing my own perl scripts. Yes, I was able to write many useful scripts without fully understanding many of the concepts I was using. I'm anticipating that the Dancer course will be equally effective. I recommend that the Catalyst community work with Andrew Solomon and Geekuni to create and promote courses that would support Catalyst (and prerequisites) training. Full Disclosure - I'm a perl newbie, and I'd love to learn to build useful web applications with Catalyst. :) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
My greatest concern is only that we keep this accessible, no strings, no branches, etc. how can we best do this? On 03/01/15 22:44, Lance A. Brown wrote: Robert Brown wrote on 1/3/2015 5:36 PM: Is this something we can resolve, or simply make better as its install process, that maybe needs explaining better? I don't think it can be resolved unless Catalyst wants to move in the same direction Mojolicious has taken, which I don't agree with. I hesitate to call it a warning, but some kind of note in the documentation and or at the beginning of the Catalyst install process to let the user know it will take some time would be useful. --[Lance] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
There is at least one other potential newbie entrance point into Catalyst. That is where he/she installs a fully functional application (generally a blog, CMS, forums, etc.), then slowly begins contributing within a plugin architecture, then full applications, as his/her understanding of how the parts work expands. Or at least, the Catalyst app user will hire someone to work on his application. :) Octavian said: Imho a beginner should not start by creating best practice apps, but apps which help him/her to understand each step as easy as possible. She or he just need to know that there are better ways that will be learned later. Your 2012 Catalyst Advent Calendar articles Catalyst in 9 Steps embodied that principle nicely. I'd like to see those articles extended further, and have them linked in the official documentation. Why not set a documentation goal that would allow a perl newbie with Perl Beginner/(Intermediate) under his/her belt, be able to start hacking on a Catalyst app, with relevant documentation to take them all the way to a production ready, best practice site? That is where those 2012 Advent articles were heading, I think that is a great idea. IMHO :) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
Hi, i'm currently building a catalyst-based CMS - it is fully working, but needs some help to make it open source and add some more features. Based on Catalyst, Template Toolkit, DBIx::Class, and some more great Perl-Modules. Multiple Rights and Roles - combined with a great Drag-n-Drop-Interface for custom elements. Currently i'm searching for contributors, those who will understand my English ;) and helping to make it open source! I also have paying customers for a long list of features! For those who are interested in, i will gave a online presentation. Please contact me if you like to contribute! Best regards, Jens Am 18.01.2015 um 19:36 schrieb r...@hiranyaloka.com: There is at least one other potential newbie entrance point into Catalyst. That is where he/she installs a fully functional application (generally a blog, CMS, forums, etc.), then slowly begins contributing within a plugin architecture, then full applications, as his/her understanding of how the parts work expands. Or at least, the Catalyst app user will hire someone to work on his application. :) Octavian said: Imho a beginner should not start by creating best practice apps, but apps which help him/her to understand each step as easy as possible. She or he just need to know that there are better ways that will be learned later. Your 2012 Catalyst Advent Calendar articles Catalyst in 9 Steps embodied that principle nicely. I'd like to see those articles extended further, and have them linked in the official documentation. Why not set a documentation goal that would allow a perl newbie with Perl Beginner/(Intermediate) under his/her belt, be able to start hacking on a Catalyst app, with relevant documentation to take them all the way to a production ready, best practice site? That is where those 2012 Advent articles were heading, I think that is a great idea. IMHO :) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ -- Freiberuflicher Software-Entwickler Büro: 02271/462009 Skype: jens.gassmann E-Mail: jens.gassm...@atomix.de ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
From: r...@hiranyaloka.com I think that one of the main use of Perl is to create web apps. And the best way of creating web apps is by using a web framework. And the most developed web framework for Perl is Catalyst. But those who prefer other frameworks do it because they consider Catalyst too complex and hard to understand. So yes, a more clear documentation for Catalyst should be very helpful. Newbies might have the time and willing to write it, but they might not know what to write. :) So... applying for a grant to do it may be the solution. --Octavian Good documentation is clearly necessary, but I don't think that it will by itself be enough to attract newbies. What else do you think that it may attract you? I am an interested newbie, so perhaps I can add something to the conversation. My impression is that Catalyst is not so complex by itself, but it sits at the top of a pyramid of knowledge domains that are both broad and deep. MVC (each letter is a book in itself), Perl/CPAN, OO, web servers, security, web hosting (your shared hosting won't work), etc. What did I miss? The loosely coupled Catalyst approach to web frameworks therefore benefits from a loosely coupled approach to Catalyst training. What's the minimum required knowledge to create a best practice web application using Catalyst? Each area requires a loosely coupled learning module, that both stands on its own, and directly supports a minimal, yet best practice prerequisite understanding necessary for integration into a Catalyst application. Imho a beginner should not start by creating best practice apps, but apps which help him/her to understand each step as easy as possible. She or he just need to know that there are better ways that will be learned later. When we say that Catalyst is hard/easy or elegant/confusing for beginners we compare it with other web frameworks, but the apps made with all web frameworks need to interact with a web server, use OO, CPAN modules, should take care of security, should be installed on a remote server etc, so it is not a big difference. Dancer examples are nice and sweet, much more elegant than Catalyst's examples, most of them in just a single file, but in real world applications we may want to split the web apps in more modules for a better maintenability, we might need to access more databases, we might want to use more complex URL dispatching styles, and in that case we would see that if we would do those things in a Dancer app, that app might not be so elegant anymore. It sounds very good that Mojolicious doesn't require other CPAN modules but it offers its own modules for many things, and it looks like it would be much easier to install a Mojolicious app, but unless the app is simple enough we may still need to use other CPAN modules, so we should still need to be able to use cpan or cpanm. And in that case, it wouldn't be a big problem to install a large distribution like Catalyst either. Beginner may mean many things, so it is not very clear what recommendations you are searching for. For a Perl - beginner level it is recommended to use the common Perl best practices regarding the variables/subroutine naming, indentation etc, for a web developer beginner is recommended to learn about HTTP and CGI protocols, how web servers work, about security in web apps, for a Catalyst beginner is recommended to read: http://dev.catalystframework.org/ and the POD docs in Catalyst::Manual, trying to concentrate on Catalyst - related code and not DBIx::Class or Template-Toolkit or different form processors if you haven't used them yet. The Catalyst docs are not very good for real beginners that have never used a web framework and also never used an ORM or templating system. Many of them give best practice examples which may be harder to understand by a beginner because they contain Catalyst code intermixed with code from different other modules and a beginner may not know where ends Catalyst and starts DBIx::Class for example. This is why is said that Catalyst has a steap learning curve. It may be very helpful if the beginner first starts by learning to use a simple RDBMS like MySQL or SQLite and DBIx::Class ORM which is the prefered ORM by most and also Template-Toolkit which is the preferred templating system, even only superficially, and only after that start learning to use Catalyst because then it would be much easier to see that Catalyst is just a glue between other modules and that it is not hard to use it. --Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
Octavian said: Imho a beginner should not start by creating best practice apps, but apps which help him/her to understand each step as easy as possible. She or he just need to know that there are better ways that will be learned later. Your 2012 Catalyst Advent Calendar articles Catalyst in 9 Steps embodied that principle nicely. I'd like to see those articles extended further, and have them linked in the official documentation. Why not set a documentation goal that would allow a perl newbie with Perl Beginner/(Intermediate) under his/her belt, be able to start hacking on a Catalyst app, with relevant documentation to take them all the way to a production ready, best practice site? That is where those 2012 Advent articles were heading, I think that is a great idea. IMHO :) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
Hi Jens, On Sun, 2015-01-18 at 20:16 +0100, Jens Gassmann wrote: i'm currently building a catalyst-based CMS - it is fully working, but needs some help to make it open source and add some more features. [...] For those who are interested in, i will gave a online presentation. Please contact me if you like to contribute! I'm the main author of ShinyCMS*, which is also an open source Catalyst-based CMS with a variety of features (pages, blogs, shop, forums, mailshots, etc etc). I'd love to learn more about your CMS and see if there are any useful ways we can work together, maybe even re-use some of each other's code! :) Regards, Denny * http://shinycms.org / https://github.com/denny/ShinyCMS ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
From: r...@hiranyaloka.com Octavian said: Imho a beginner should not start by creating best practice apps, but apps which help him/her to understand each step as easy as possible. She or he just need to know that there are better ways that will be learned later. Your 2012 Catalyst Advent Calendar articles Catalyst in 9 Steps embodied that principle nicely. I'd like to see those articles extended further, and have them linked in the official documentation. Yes, my intention was to show a few really simple ways of using Catalyst without an ORM or other CPAN modules as first steps of learning Catalyst by a beginner, even most of those steps are not intended to be used in production. It would have been very good to have the time to continue the serial and show more and more advanced steps by adding one by one more CPAN modules or Catalyst components, show different URL dispatching types from the most simple to the most complex, show how to use REST etc. Why not set a documentation goal that would allow a perl newbie with Perl Beginner/(Intermediate) under his/her belt, be able to start hacking on a Catalyst app, with relevant documentation to take them all the way to a production ready, best practice site? The people who know Catalyst the best are very occupied so they probably don't have the time to also maintain the documentation very well. Catalyst is mainly used for serious projects and they are probably thinking that the main target audience are the advanced developers, so a documentation/book for beginners probably was not considered a priority. --Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
The catalyst docs could do with a substantial review, they haven't had much attention lately. In particular there could do with being a good index. I think the issue with people thinking catalyst is too big/complex is that lots and lots of developers are used to a procedural approach to dealing with web applications, and have troulble with a couple of things. These are: 1. Lots of people are in the habit of writing procedural web apps, and don't feel that they want to shift over to a more OO style. 2. Some aspects of the dispatcher freak people out until they learn it (and especially until they get comfortable with chained) and this is a bit of a point of resistance. 3. Catalyst used to be hard to install (and catalyst had a lot of influence on improving the cpan toolchain during the relatively early days), but this isn't the case any more, but the perception lingers in places. Maybe the solution is in part for someone to write a Catalyst::Manual::Unsweetened in the same sprit as Moose::Manual::Unsweetened in order to gently guide people towards catalyst from something they're less familiar with. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
umm from something they're *more* familiar with. On Sun, Jan 4, 2015 at 7:43 AM, Kieren Diment dim...@gmail.com wrote: The catalyst docs could do with a substantial review, they haven't had much attention lately. In particular there could do with being a good index. I think the issue with people thinking catalyst is too big/complex is that lots and lots of developers are used to a procedural approach to dealing with web applications, and have troulble with a couple of things. These are: 1. Lots of people are in the habit of writing procedural web apps, and don't feel that they want to shift over to a more OO style. 2. Some aspects of the dispatcher freak people out until they learn it (and especially until they get comfortable with chained) and this is a bit of a point of resistance. 3. Catalyst used to be hard to install (and catalyst had a lot of influence on improving the cpan toolchain during the relatively early days), but this isn't the case any more, but the perception lingers in places. Maybe the solution is in part for someone to write a Catalyst::Manual::Unsweetened in the same sprit as Moose::Manual::Unsweetened in order to gently guide people towards catalyst from something they're less familiar with. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
I find that getting involved in a project like Catalyst is much like releasing your own CPAN module - possibly daunting at first, hence some reluctance? From my own experience only, it took years to finally find something I was comfortable to release, but when I did, it then starts to flow. To me, it's all about that initial involvement... that first step, and making it as painless as possible. Maybe I've been skipping things recently, do we have a roadmap? A simple list of issues, bugs, and feature-requests? Something Trello-esque maybe? and as small as possible? Do we have a documented workflow? Perhaps even down to copy paste commands to cut a branch, etc. I'd personally love to pick up a simple documentation fix to get involved. More to get a feel of actually contributing back to the codebase, as simple as that sounds, I feel it may be a huge stumbling block for most. If we make simpler, we may have more success? Just some random 2-cents... On 03/01/15 20:08, Octavian Rasnita wrote: From: http://www.catalystframework.org/calendar/2014/21 I've also considered making a request for a grant from the Perl Foundation in order to work on these docs, and wonder what you all think of that :) I think that one of the main use of Perl is to create web apps. And the best way of creating web apps is by using a web framework. And the most developed web framework for Perl is Catalyst. But those who prefer other frameworks do it because they consider Catalyst too complex and hard to understand. So yes, a more clear documentation for Catalyst should be very helpful. Newbies might have the time and willing to write it, but they might not know what to write. :) So... applying for a grant to do it may be the solution. --Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
From: Kieren Diment The catalyst docs could do with a substantial review, they haven't had much attention lately. In particular there could do with being a good index. I think the issue with people thinking catalyst is too big/complex is that lots and lots of developers are used to a procedural approach to dealing with web applications, and have troulble with a couple of things. These are: 1. Lots of people are in the habit of writing procedural web apps, and don't feel that they want to shift over to a more OO style. Yes, but shifting to OO style requires a very good knowledge of the entire module stack used. If these modules are too smart, the documentation should explain they very well. 2. Some aspects of the dispatcher freak people out until they learn it (and especially until they get comfortable with chained) and this is a bit of a point of resistance. And I'd say that the fact that Catalyst uses method attributes which in general are discouraged and very rarely found in other projects is another obstacle. Probably some people might like to be able to write their own hello world script that also uses method attributes in order to see how they work and what are their limits in order to understand then a more complex system of attributes in Catalyst. 3. Catalyst used to be hard to install (and catalyst had a lot of influence on improving the cpan toolchain during the relatively early days), but this isn't the case any more, but the perception lingers in places. :-) I think that the last time I also installed Catalyst or a Catalyst component in a hurry by using --force. I spent today a pretty long time trying to install RapidApp, which is a Catalyst extension, but finally I abandoned the idea. I installed a few modules by using ActiveState's ppm and a few others after looking in the .log file with the errors generated by cpanm, but there are other modules required, like JSON::DWIW which don't appear to be made to work under Windows. --Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
Kieren Diment wrote on 1/3/2015 3:43 PM: 3. Catalyst used to be hard to install (and catalyst had a lot of influence on improving the cpan toolchain during the relatively early days), but this isn't the case any more, but the perception lingers in places. Catalyst isn't nearly as difficult to install these days, but it still feels like you're installing most of CPAN in order to get Catalyst. And it still takes a frickin' long time. --[Lance] -- GPG Fingerprint: 409B A409 A38D 92BF 15D9 6EEE 9A82 F2AC 69AC 07B9 CACert.org Assurer ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
Is this something we can resolve, or simply make better as its install process, that maybe needs explaining better? On 03/01/15 22:26, Lance A. Brown wrote: Kieren Diment wrote on 1/3/2015 3:43 PM: 3. Catalyst used to be hard to install (and catalyst had a lot of influence on improving the cpan toolchain during the relatively early days), but this isn't the case any more, but the perception lingers in places. Catalyst isn't nearly as difficult to install these days, but it still feels like you're installing most of CPAN in order to get Catalyst. And it still takes a frickin' long time. --[Lance] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advent Calendar... Grant proposal...
Robert Brown wrote on 1/3/2015 5:36 PM: Is this something we can resolve, or simply make better as its install process, that maybe needs explaining better? I don't think it can be resolved unless Catalyst wants to move in the same direction Mojolicious has taken, which I don't agree with. I hesitate to call it a warning, but some kind of note in the documentation and or at the beginning of the Catalyst install process to let the user know it will take some time would be useful. --[Lance] -- GPG Fingerprint: 409B A409 A38D 92BF 15D9 6EEE 9A82 F2AC 69AC 07B9 CACert.org Assurer ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
