i started using github somewhere in 2009 iirc. i was a bit reluctant to use it back at that time, especially because of its speed (or lack of, actually)... and because i already hosted my projects of repo.or.cz.
however, i'm now really glad i started using it. speed is no longer a problem, and it provides really nice features. cia integration, network graphs, comments on commits, watching repos (even if i'm not totally happy with it right now), and of course... pull requests!
i was away this week-end, and found 4 pull requests in my mailbox for my modules when i came back. integrating other's work has never been easier with git and github which allows people to fork at will. that's the new way of writing code: create the basic stub of your module, and wait for others to enhance it! :-) git plugin for dist-zilla now supports pushing to a different branch, supports the new dist-zilla-tester framework and the bundle @git now accepts multi-valued args.
dvcs are a bit harder to grasp at first, but once you understand the concepts, they're really a killer application - especially when coupled with a cooperative platform such as github.
2010-04-07
2010-03-31
dzil activity
of course, you are aware that dzil v2 is out, with lots of exciting new features, brought to you by rjbs and the perl foundation.
but it's only one side of the activity floating around dist-zilla... indeed, as dagolden, aevar and others try dzil, they (of course) like it, and start contributing their own plugins.
here's a list of new plugins landed on cpan... first some additional author tests:
some plugins to complete meta-data:
some plugins to generate additional files:
some plugins to compute your next version number:
and finally some bundles:
you can install all of them in one go via task-dist-zilla.
they are also available in mandriva, and suggested when installing dist-zilla...
but it's only one side of the activity floating around dist-zilla... indeed, as dagolden, aevar and others try dzil, they (of course) like it, and start contributing their own plugins.
here's a list of new plugins landed on cpan... first some additional author tests:
- CheckChangesTests - check changelog
- CheckExtraTests - runs xt/ tests, but don't copy them to t/
- DistManifestTests - check manifest
- HasVersionTests - check all your modules have a version
- KwaliteeTests - check your kwalitee
- MinimumVersionTests - check minimum perl version needed
- PodSpellingTests - check pod spelling
- PortabilityTests - check if your code is portable
- SynopsisTests - check if code in your synopsis compiles
- UnusedVarsTests - detects unused vars
- ReportVersions - additional test to report version
some plugins to complete meta-data:
- Bugtracker - http://rt.cpan.org/Public/Dist/Display.html?Name=xxxx
- HomePage - http://search.cpan.org/dist/xxxx
- ModuleBuild::Custom - for mb
- OverridableMakeMaker - for eumm
some plugins to generate additional files:
- FatPacker - creates a script with all dependencies packed
- InstallGuide - creates an INSTALL file
- ReadmeMarkdownFromPod - README.mkdn file
some plugins to compute your next version number:
- BumpVersionFromGit - version taken from last git tag
- VersionFromPrev - classic perl versions, 1.00 to 1.99
and finally some bundles:
you can install all of them in one go via task-dist-zilla.
they are also available in mandriva, and suggested when installing dist-zilla...
2010-03-23
how to obsolete a cpan dist?
my autoprereq plugin for dist-zilla is now going core. however, it's currently existing as a dist of its own within cpan... since the module does not change name, what is needed to make sure rjbs can upload dzil v2 when it's ready? is giving co-maint rights on pause enough? will i have to remove previous tarballs?
the same kind of question can be asked for obsoleting a given module. there's (afaik) no way to tell cpan / cpanplus that foo::bar is replacing bar::foo... those problems are tackled for linux distribution packages, could we reuse some of their logic here?
the same kind of question can be asked for obsoleting a given module. there's (afaik) no way to tell cpan / cpanplus that foo::bar is replacing bar::foo... those problems are tackled for linux distribution packages, could we reuse some of their logic here?
2010-03-15
activity in git plugin for dist-zilla
it's been a busy week for dist-zilla-plugin-git...
first, there was some test fixes to work with latest dist-zilla (thanks to ricardo), and also to support git 1.7.
the git plugin then saw support for annotated tags which is now the default - but christopher madsen restored the possibility to use lightweight tags. he then refactored commit message generation, in order to allow a custom commit message. not only that, but he also brought to ability to specify which files are allowed to be dirty, and automatically committed.
then david golden jumped in, and scratched his itches: support for empty lines in changelog and possibility to specify which branch(es!) to push to. all of that with new tests - and some existing test fixes! \o/
git support in dist-zilla is now in a pretty good shape. report bugs if you miss your pet-peeve... or even better: fork the code and send me pull requests once the code is doing what you want!
first, there was some test fixes to work with latest dist-zilla (thanks to ricardo), and also to support git 1.7.
the git plugin then saw support for annotated tags which is now the default - but christopher madsen restored the possibility to use lightweight tags. he then refactored commit message generation, in order to allow a custom commit message. not only that, but he also brought to ability to specify which files are allowed to be dirty, and automatically committed.
then david golden jumped in, and scratched his itches: support for empty lines in changelog and possibility to specify which branch(es!) to push to. all of that with new tests - and some existing test fixes! \o/
git support in dist-zilla is now in a pretty good shape. report bugs if you miss your pet-peeve... or even better: fork the code and send me pull requests once the code is doing what you want!
2010-03-09
on testing
testing is good for your modules. even the ones you know work as intended. case in point: i wanted to refactor curses::toolkit::object::coordinates to use moose.however, refactoring such a core component of curses::toolkit without a test suite did not sound such a good idea...
therefore i wrote some tests for this module - and i discovered 2 bugs in this class. a small one that made an error message totally useless, and a serious one that affected the semantics of some methods.
so, not counting the fact that refactoring was quite easy once the test suite was in place, i also found some real bugs in the code. those tests were not very funny to write, but at least i know that the roi was very good! :-)
therefore i wrote some tests for this module - and i discovered 2 bugs in this class. a small one that made an error message totally useless, and a serious one that affected the semantics of some methods.
so, not counting the fact that refactoring was quite easy once the test suite was in place, i also found some real bugs in the code. those tests were not very funny to write, but at least i know that the roi was very good! :-)
2010-03-03
tk::action to simplify access to a gui action
in a typical graphical application, menu entries are often also available in toolbars or other widgets. and sometimes, you want to enable or disable a given action, and this means having to update all those entries and widgets everywhere this action is allowed / forbidden.
this is not fun.
therefore, i wrote tk::action, a module to help managing actions in a tk gui: just create a new object, associate some widgets and bindings with add_widget() / add_binding() and then de/activate the whole action at once with enable() or disable().
2010-02-24
a progressbar for curses-toolkit
curses::toolkit is the promising toolkit for writing curses applications with perl. it follows a gtk-like api, and supports theming. it is using poe for its event loop (although one can craft its own loop), and currently begins a loose moose conversion.
however, the set of widgets is currently a bit restricted: hbox, vbox, buttons, label, entries, windows... so, i wrote yesterday a progressbar widget. it's a bit difficult to understand at a glance where to put code, but i finally nailed a rough first version - it needs to be polished, though. once a listbox widget will be available, the toolkit will be sufficient for a lot of tasks.
lots of stuff remains to be done of course: moose-ification to get rid of its hand-crafted roles, building a real test suite (how the heck are we supposed to test a curses toolkit?), completing the widget set... volunteers welcome.
however, the set of widgets is currently a bit restricted: hbox, vbox, buttons, label, entries, windows... so, i wrote yesterday a progressbar widget. it's a bit difficult to understand at a glance where to put code, but i finally nailed a rough first version - it needs to be polished, though. once a listbox widget will be available, the toolkit will be sufficient for a lot of tasks.
lots of stuff remains to be done of course: moose-ification to get rid of its hand-crafted roles, building a real test suite (how the heck are we supposed to test a curses toolkit?), completing the widget set... volunteers welcome.
Subscribe to:
Posts (Atom)
