Created
April 25, 2019 15:11
-
-
Save jberger/93c719cf9e50ff41fbcdbfc88fb5e399 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<jberger> so as people are assembling for PTS (which I sadly am not able to attend this year) I want to float an idea that I've been thinking a lot about | |
and it specifically derives from building out the CI/CD system we're using at $work | |
I'd like there to be some way to delegate the module version to the META file | |
this is handy because I can build a darkpan dist and not need to modify the code in order to do so (if the version isn't in the code) | |
but it also gives us some other nice perks | |
no need to statically parse the version out of the code | |
and an opportunity to newer/better enforce standards on versions declared in this way | |
I'd see it as opt in in the module probably | |
use VersionFromMETA 'Distname'; or some such | |
we'd have to have tooling that would make the meta available obviously | |
for a first cut it could be done like a share file | |
but obviously we could do other things since we control the toolchain | |
I could probably proof of concept it on CPAN if people like, it would involve build-tool extensions that grab the META.json file and put it in the share | |
but that would break static parsing | |
a feature in the long term but a detriment now | |
<ether> the meta 'provides' key already contains the canonical version, so if it exists the module itself does not get statically parsed by PAUSE and friends | |
<jberger> oh, right | |
well that's what I'd be using from the module too | |
but I'd be having the distribution builder writing the provides for me |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment