Not directly relevant but similar in concept prior art: there's a package for emacs which lets you install directly from the github repo rather than pulling from its official package repos (MELPA/ELPA) Quelpa. It more or less pulls the source and does the equivalent of a make dist then installs that.
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply]
[d/l] |
Even if CPAN clients can as easily install from GitHub, I like the ease of which a CPAN mirror can be used offline. I do maintain private CPAN-like repositories for personal/work use and should probably "publish" there more often instead of to CPAN for things like these. But I do like the nice things the ecosystem gives me, e.g. RT and CPAN Testers.
| [reply] |
"I do like the nice things the ecosystem gives me, e.g. RT and CPAN Testers" Github has 'issues' for rt, and allows the use of continued integration testing (free tiers exist for most OS IIRC) for cpan testers.
| [reply] |
I much prefer RT over GitHub issues. I have all (or pretty much all) of my CPAN releases on Github, but have disabled the Github issue trackers in favour of RT.
CI like Travis and AppVeyor are great and I use them for many of my distributions, but there have been many times that my code has passed all its tests on Travis, but CPAN Testers have found issues. CPAN Testers will be testing your distribution in a wider variety of environments. While CIs might get you a handful of operating systems and a bunch of different Perl versions, CPAN Testers will give you a variety of CPU architectures and OS versions, different C compilers, older versions of your dependencies, different combinations of your optional dependencies, different locales and environment variables, etc. Yes, you can test some of this with CI if you think through and anticipate the combinations in advance, but CPAN Testers gives you a set of random variations that is very valuable.
| [reply] |