Shawn, I haven’t reached out to kmx. Want to do so? Please do! Perhaps it can be discussed on an issue on https://github.com/PDLPorters/pdla-core/issues
Everyone: The currently-conceived strategy for carving chunks out of PDLA::Rest: * identify a small, meaningful part of it that fits together – maybe one module, maybe a few * make a new repo for it * use the techniques in https://github.com/PDLPorters/devops/blob/master/NOTES.md to split out those parts in the new repo – coming soon, a script to reorganise a shallow EUMM set of files into something under lib/ * where that new chunk has external dependencies, pull the code managing that out into an Alien distro, probably using Alien::Build If you’d like to get involved with helping do some of this, create an issue to let me know. I’ll help you through it! One idea I had a while ago was to make PDLA::Rest depend on the carved-out bits, so PDLA::Rest would still install everything. However, I cannot imagine a situation that would specifically want to be able to install the entirety of the “kitchen-sink”, and also I believe it to be a bad idea to enable it – isolating bits of software from depending on each other is the only way to make this difficult stuff relatively less difficult. I’ve identified a bit of PDLA::Core that can be extracted: Inline::Pdlapp, which isn’t used by “core” functionality and should be separate. That’s next! Here’s one way to have a go with PDLA, recapped from a different message: * install a new perl; either a copy of Strawberry Perl Portable on Windows, or using https://metacpan.org/pod/App::perlbrew * (on perlbrew, switch to new perl, and create a local-lib: perlbrew use 5.28.1; perlbrew lib create experiment-1; perlbrew use 5.28.1@experiment-1<mailto:5.28.1@experiment-1>) * installed a specific version of PDLA::Core: cpanm PDLA::Core@2.019104 (note that when running a different experiment, you wouldn’t have to install a different perl, you could just make a different local::lib; or just use the same everything and reuse the instructions!) Then you can document those steps for your paper when you publish results. Even if PDLA::Core changes after that, even if a version is released that breaks something you depend on, it doesn’t matter for reproducing results; people can still install exactly the same perl and PDLA versions you had, and they are guaranteed the same results. As mentioned previously, I now have a plan for how to make this easier with a script, called “repro”. In due course it will allow easy use of Docker to transparently do all these things, effortlessly! Let me know if you’ve tried PDLA::Core. Let me know if you’ve had problems! Best regards, Ed From: Shawn Laffan<mailto:shawnlaf...@gmail.com> Sent: Friday, April 26, 2019 2:29 AM To: pdl-devel@lists.sourceforge.net<mailto:pdl-devel@lists.sourceforge.net> Subject: [Pdl-devel] PDL/PDLA and Strawberry Perl PDL editions It's good to see renewed development of PDL and PDLA. Are the maintainers of Strawberry perl aware of the shift to PDLA? (They are probably on this list, but have not yet commented). PDL builds cleanly on a plain Strawberry perl, but not all components are built since the extra libs like libproj and libhdf are not provided. Those only come with the PDL editions. PDLA (or PDLA::Rest) could depend on Alien packages for those libs, perhaps as an opt-in, but that's potentially a lot of Alien wrangling and long build times if they don't come prepackaged. Shawn. ________________________________ ________________________________ _______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
_______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
