When to factor out code into a stand-alone CPAN release?
Hi,
In a recent issue, Chris proposed to factor out part of the code base into a stand-alone CPAN release (which would IMO mean into a more-or-less stand alone project). The same happened some years ago when he factored out DBObject into PGObject, so, we have precedence here. The other way around (refactored our code to use releases from CPAN) has happened as well.
From my perspective, the reasons to refactor our code to make use of
(pre-existing) CPAN code are clear: * Using pre-existing code from CPAN outsources maintenance (to an external maintainer) * Opens up opportunities for wider use in our own code base, because usually replaces specific with generic code * Ensures better testing of code in a wide variety of settings (hopefully with bugfixes) * Improves code-sharing in the wider Perl community (hopefully free-ing up resources to take Perl and its modules a step further)
To me, the other way around would roughly work the same way. Meaning, that we should be thinking about placing our code on CPAN, if: * Our code is sufficiently generic to solve problems for others * Others can depend on us to do the maintenance of the code * Our code comes with sufficient quality assurance measures to be helpful to others * Our code is sufficiently stable not to require large refactorings to the projects (which would mean that people can't really depend on the code - yet)
Especially the last point - I think - is tricky: when largish refactorings are in order, the fact that part of the code being refactored is loaded onto Travis CI through CPAN is a major limitation on the speed that can be had during the refactoring. The recent PGObject 1.x->PGObject 2.x refactoring showed that.
I'm wondering: Is there anything else to be considered? (Reasons to factor out, problems to be met after having separated, etc...)
Regards,
Hi,
Although CPAN can be seen as a distribution mean, I do not think that we fit there.
For me, their purpose is mostly to distribute packages and libraries used to fit in a larger application and that ain't LedgerSMB, although one could argue that it would fit in a suite of business applications.
We should use a consistent set of CPAN/distro packages as much as possible to ensure quality, outsource maintenance and to free ourselves from specific versions and distributions.
But at the end, we will remain a business application, focused on a very specific need.
Yves
Le 2017-08-26 à 12:06:14, Erik Huelsmann a écrit :
Hi,
In a recent issue, Chris proposed to factor out part of the code base into a stand-alone CPAN release (which would IMO mean into a more-or-less stand alone project). The same happened some years ago when he factored out DBObject into PGObject, so, we have precedence here. The other way around (refactored our code to use releases from CPAN) has happened as well.
From my perspective, the reasons to refactor our code to make use of (pre-existing) CPAN code are clear: * Using pre-existing code from CPAN outsources maintenance (to an external maintainer) * Opens up opportunities for wider use in our own code base, because usually replaces specific with generic code * Ensures better testing of code in a wide variety of settings (hopefully with bugfixes) * Improves code-sharing in the wider Perl community (hopefully free-ing up resources to take Perl and its modules a step further)
To me, the other way around would roughly work the same way. Meaning, that we should be thinking about placing our code on CPAN, if: * Our code is sufficiently generic to solve problems for others * Others can depend on us to do the maintenance of the code * Our code comes with sufficient quality assurance measures to be helpful to others * Our code is sufficiently stable not to require large refactorings to the projects (which would mean that people can't really depend on the code - yet)
Especially the last point - I think - is tricky: when largish refactorings are in order, the fact that part of the code being refactored is loaded onto Travis CI through CPAN is a major limitation on the speed that can be had during the refactoring. The recent PGObject 1.x->PGObject 2.x refactoring showed that.
I'm wondering: Is there anything else to be considered? (Reasons to factor out, problems to be met after having separated, etc...)
Regards,
-- Bye,
Erik.
http://efficito.com http://efficito.com/ -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
devel mailing list devel@lists.ledgersmb.org https://lists.ledgersmb.org/mailman/listinfo/devel
Hi Yves,
Although CPAN can be seen as a distribution mean, I do not think that we fit there.For me, their purpose is mostly to distribute packages and libraries used to fit in a larger application and that ain't LedgerSMB,
Correct. However, the point was about factoring out parts of the application for them to *become* libraries and be released stand-alone.
From that point on, releasing changes in that software would have its own
Travis CI setup and the integration with LedgerSMB can only be tested by releasing through CPAN, just like PGObject. Or at least, that's my interpretation.
although one could argue that it would fit in a suite of business applications.
We should use a consistent set of CPAN/distro packages as much as possible to ensure quality, outsource maintenance and to free ourselves from specific versions and distributions.
But at the end, we will remain a business application, focused on a very specific need.
Yves Le 2017-08-26 à 12:06:14, Erik Huelsmann a écrit :
Hi,
In a recent issue, Chris proposed to factor out part of the code base into a stand-alone CPAN release (which would IMO mean into a more-or-less stand alone project). The same happened some years ago when he factored out DBObject into PGObject, so, we have precedence here. The other way around (refactored our code to use releases from CPAN) has happened as well.
From my perspective, the reasons to refactor our code to make use of (pre-existing) CPAN code are clear:
- Using pre-existing code from CPAN outsources maintenance (to an
external maintainer)
- Opens up opportunities for wider use in our own code base, because
usually replaces specific with generic code
- Ensures better testing of code in a wide variety of settings (hopefully
with bugfixes)
- Improves code-sharing in the wider Perl community (hopefully free-ing
up resources to take Perl and its modules a step further)
To me, the other way around would roughly work the same way. Meaning, that we should be thinking about placing our code on CPAN, if:
- Our code is sufficiently generic to solve problems for others
- Others can depend on us to do the maintenance of the code
- Our code comes with sufficient quality assurance measures to be helpful
to others
- Our code is sufficiently stable not to require large refactorings to
the projects (which would mean that people can't really depend on the code
- yet)
Especially the last point - I think - is tricky: when largish refactorings are in order, the fact that part of the code being refactored is loaded onto Travis CI through CPAN is a major limitation on the speed that can be had during the refactoring. The recent PGObject 1.x->PGObject 2.x refactoring showed that.
I'm wondering: Is there anything else to be considered? (Reasons to factor out, problems to be met after having separated, etc...)
Regards,
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
devel mailing listdevel@lists.ledgersmb.orghttps://lists.ledgersmb.org/mailman/listinfo/devel
devel mailing list devel@lists.ledgersmb.org https://lists.ledgersmb.org/mailman/listinfo/devel
participants (2)
-
Erik Huelsmann -
Yves Lavoie, GaYLi