Deprecate tido/plgToMSS and gulp

[ahankinson]

Having recently got my installation back up and running, I'm reminded again of just how fragile JavaScript dependencies can be. I was only able to get things up and running by adding a graceful-fs override due to incompatibilities with gulp 4 and npm. So I'm thinking we should replace them with our own toolchain. This took about an hour and a half of Googling.

(Note: I'm not suggesting we deprecate the stuff used for testing, but this seems to be fairly well isolated.)

Having a look at the things we do use in the tido/plgToMSS repo, I think it's not anything that can't be replaced pretty easily. AFAIK we only use buildPlg and deployPlg.

So my questions and comments are:

• What language? Python is obvious, but might require some setup / Windows stuff? Bash is probably the most portable, but also a bit of a pain to write and maintain.
• Replacing plgconfig.js -- I'm imagining the same thing but using YAML.
• I'd like to keep having the recompile-on-change that the develop gulp command has, so that might have a bearing on what language we use.

This would be post-release.

[craigsapp]

Bash is probably the most portable, but also a bit of a pain to write and maintain.

PERL would be better than Bash since it is just as ubiquitous and less of a pain to write and easy to maintain. (in particular easier to maintain than Python code).

See:
https://github.com/rism-digital/verovio/blob/develop/emscripten/buildToolkit

Original bash script:
https://github.com/rism-digital/verovio/blob/5c220491196aa428f99ea9118bd027906de52c03/emscripten/build.sh

where I converted the original bash script for the emscripten compile command for verovio to PERL.

[ahankinson]

Perl is a hard no from me.

(unless, of course, you're voluteering to write and maintain it)

[craigsapp]

Perl is a hard no from me.

Because you do not know it? I am currently teaching a PERL class :-)

I could write a PERL script based on some current script as long as the source language is not too opaque. As I do not use Sibelius (and by extenion sibmei), so I should not be a maintainer, of course.

[ahankinson]

Given that the point of the exercise is to make the tools more maintainable, not less, then I'm not sure that writing it in a language that (I think) nobody here really uses is a good move.

[craigsapp]

If you propose to write a script in bash but do not consider PERL, then I am quite curious as to why not? You have not directly answered question, but it seems that it is due to lack of knowledge of programming in PERL.

https://xkcd.com/519

[ahankinson]

Given that you'll never use it, and that you don't even use Sibelius, nor any of the tooling here, I'm not sure why this is a problem here? There can be valid technology choices that don't conform to your own preferences.

I get it -- you don't like Python. That's great. It's still a perfectly valid choice, and you'll never have to use it. Win-win!

I was polling those people who do contribute to this project to see what they thought.

I proposed bash because I know some people might want a simple shell script. I also noted that it would be "a pain to write and maintain," particularly because it involves:

• file watchers (probably need a separate utility)
• file parsing + regex + string copying
• config file loading

None of these are impossible with bash, but they are certainly easier (for me, at least) in higher-level languages. Given that we'll be the ones left holding the bag afterwards, then it makes sense to take the easiest route, don't you think?

[craigsapp]

Note that I am not making a comparison between Python and PERL, but rather bash and PERL. There would be other factors that would be used to decide between PERL and Python implementations (such as Windows is less suitable for PERL, and the ability to program in PERL/Python).

I proposed bash because I know some people might want a simple shell script.

Yes if it is simple enough, then a bash script is preferable to a PERL script. But any minor complications such as command-line arguments, functions, even if-statements in the program makes bash scripting much more complicated to deal with since its syntax is not very harmonious. Compare the Bash and PERL scripts for building the emscripten version of verovio links above. Note that the emscripten build script has 8 contributors:

And I suspect that I am the only one of them that knows PERL. I wanted to extend the bash script and balked at doing that, and so I volunteered to convert the script to PERL.

Comparing PERL to Python: I note over the years that PERL is much more stable than Python, resulting in that it is easier to maintain over longer periods of time (provided that you have familiarity with PERL, of course). PERL is more suited to unix environments than non-unix environments, which could be a determining factor (bash is even more tightly binded to linux/unix environments). PERL comes pre-installed with every unix/linux system, unlike Python which has many different ways to install, and the installation process is different in different operating systems. Typically I have to have several different versions of Python installed for various software packages that require a specific version of Python.

PERL is the primary source of regular expressions in languages such as Javascript, C++ and Python.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp
https://www.johndcook.com/blog/cpp_regex
https://www.johndcook.com/blog/python_regex

And PERL was designed for file management in mind (unlike C or C++, which I would not use to write a maintenance script).

Here is my PERL class's slides I am working on for this week, which are about regular expressions:
https://docs.google.com/presentation/d/1T7ONkkEhK15BCHLonACX5aCrSC58temWJrxf0FRGmV8/edit#slide=id.p4