Re: RFC - Module::Cooker
by kcott (Archbishop) on Dec 02, 2013 at 07:57 UTC
|
G'day boftx,
I wondered if this had the ability to add new modules to a distribution.
For example, you create Some::Module::X; later you want subclasses Some::Module::X::Y and Some::Module::X::Z.
I looked through the code (albeit briefly) and couldn't find anything like this.
The die "Distribution directory already exists: " ... in _process_template() rather suggests it's not possible.
I think this would be a nice feature to have.
Of course, during my minimal tour of the code, I could have missed it;
if not, perhaps consider for a later version.
As a general comment, the code looks well written, nicely formatted and easy to read.
I haven't downloaded or tested any part of it; so, that's really just a (positive) report on style.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
You are correct that it does not have a mechanism for adding a module to and existing distro, yet. I read a couple of comments elsewhere that said the desire for that feature was the inspiration for writing a sub-class to enable other modules to do that. Thinking of the general use-case in a mature project environment that is something that might be needed. I have tried to keep that in mind for future enhancements.
It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
| [reply] [Watch: Dir/Any] |
Re: RFC - Module::Cooker (File::ShareDir::Install)
by Anonymous Monk on Dec 02, 2013 at 08:37 UTC
|
| [reply] [Watch: Dir/Any] |
|
Actually Dist::Inkt is unlikely to be much help; it only does one job: produces a tarball suitable for uploading to CPAN from the project directory. (That includes building META.yml, META.json, Makefile.PL, etc.) Creating a new project directory from scratch is something outside its mandate.
However it has a companion project Dist::Inktly::Minty which does that; it should be fairly easy to subclass to do what you want. (A couple of subclasses are bundled with it.)
Update: as a general design note, if you do publish Module::Cooker... don't waste your time making it super-configurable with config files, etc. The end-users it is aimed at are Perl programmers; they are not opposed to writing Perl to get something done. So just make it easy to subclass - this is a far more powerful form of extensibility. Break everything up into small methods that can be overridden in subclasses; document them, the arguments they take and what (if anything) they're expected to return. Make sure that your command-line tools support a --cooker=Module::Cooker::MySubclass option to allow users to indicate hey want to use a particular subclass of Module::Cooker rather than the base Module::Cooker package.
use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
| [reply] [Watch: Dir/Any] [d/l] |
|
I'm not quite sure what you mean. I am using File::HomeDir in the script to get what I hope is the user's home dir so I can locate an optional local config file. With regards to data files, Module::Cooker places its data files under its own directory, see _basename_dir, but that can be overridden by specifying a local data dir if desired.
It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
I'm not quite sure what you mean ... Module::Cooker places its data files under its own directory
Pretty much what I said, don't do that, use sharedir , sharedir is the "official" way ... perldoc/pod2html... will all find your "data files" and treat them as real perl modules ... because they live in the module tree and are named like modules ... you avoid that with sharedir , its why its the "official" standard :)
Also remember to consider version-ing or even theme-ing your template sets ...
| [reply] [Watch: Dir/Any] |
|
|
Re: RFC - Module::Cooker
by educated_foo (Vicar) on Dec 02, 2013 at 14:28 UTC
|
If I were you, I would ask myself whether I was trying to create a tool to make it easier for me to create a module, or to create a tutorial for newbies. For the former, any developer who writes enough modules to make it worthwhile will probably write his own script.
lib/Module/Cooker/default/Module.pm is rather unhelpful for this: it generates 80 lines of stuff, most of which I would have to delete every time I created a module. To make your module useful, I would have to write a script to immediately delete useless things like "Stub documentation for \% package.name %\...," or read about how to create my own template which only included useful things. | [reply] [Watch: Dir/Any] [d/l] |
Re: RFC - Module::Cooker
by taint (Chaplain) on Dec 02, 2013 at 23:22 UTC
|
OK I can see on one hand, if you're a prolific Module Author. You've likely already written, or chosen a skeleton creator that suits you best. OTOH, if your a seasoned Author, but not terribly prolific. I can imagine one might look to something else, rather than write their own, that seems to best suit their style. Then OTOH, there's the "aspiring author". That has a keen sense of Perl, and is looking to cut their teeth, on their first Module.
In my humble view. I see this as potentially appealing to the latter two mentioned. Providing enough flexibility for those who could but might rather not write their own. Or as a easy "first step" for those whom are not already knowledgeable in the ways of the great CPAN.
So, to me. I wonder if it might not be wise to break it up thusly:
Module::Cooker
Module::Cooker::Templates
Module::Cooker::License
Module::Cooker::Tutorial
This construction/layout would then have the potential to appeal to a broader group. Making for easy useage, no matter your needs. Module::Cooker::Templates could provide customizable templates that anyone could (want) to use. Whereas Module::Cooker provides a "minimal" base, from which to start from. The rest, I think, speak for themselves. :)
You asked for input, and you received. :)
--Chris
#!/usr/bin/perl -Tw
use Perl::Always or die;
my $perl_version = (5.12.5);
print $perl_version;
| [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] [d/l] |
|
That Template thing is potentially a tricky bit. Flexability, and the ability to switch on demand, based on the users need(s). I think should be addressed. To my knowledge, there really isn't anything that currently addresses this as effectively, as it could. This option, if done correctly, could possibly set it apart from the others already available.
Then there's the versioning strategy. Based on what? Everyone has their preferred strategy. While some, may choose none -- if only for a "one off".
Just some thought's that come to mind.
--Chris
#!/usr/bin/perl -Tw
use Perl::Always or die;
my $perl_version = (5.12.5);
print $perl_version;
| [reply] [Watch: Dir/Any] |
|
Re: RFC - Module::Cooker
by Laurent_R (Canon) on Dec 03, 2013 at 19:02 UTC
|
Hi,
I have written quite a number of modules, but none of them has made its way to the CPAN. Mainly because most of these modules were very specific to our environment and would not be useful outside that context. But at least two modules that I wrote recently could be useful to others, if I only knew how to package them for the CPAN. Yes, I was not really convinced by the existing modules to build such skeletons, but quite possibly because I used them wrongly. If your module makes things easier, then I am definitely interested. I'll try yours, but don't expect an answer from me before at best the next weekend.
| [reply] [Watch: Dir/Any] |
|
Thanks!
When it comes right down to it, there is really only one file that is usually easier to have a tool create for you: Makefile.PL
Once that is present (containing the proper commands for ExtUtils::MakeMaker) the process boils down to this:
perl Makefile.PL
make manifest
make disttest
make dist
make distclean
At that point you should have a tarball ready for upload to PAUSE.
What the various tools do (including Module::Cooker) is create a full skeleton structure that just happens to include Makefile.PL. Based on what you (and others) have said, I should add a means to only add any missing files such as Makefile.PL to an existing directory structure.
It helps to remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
Makefile.PL # in the project root directory
lib/Foo/Bar.pm # modules named like this
script/foobar # scripts like this
bin/foobaz # ... or this
t/foo-bar.t # tests like this
xt/foo-baz.t # extra tests like this
use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
| [reply] [Watch: Dir/Any] [d/l] |