change references in test files // add 'vexflow-overrides.js'?

[aerhard]

In the test files, it could be helpful to reference to the files in VexFlow' src folder instead of the minified VexFlow script -- error messages like "a=undefined in line 1" would get more meaningful then when testing. The test files also make use of ../dist/meitovexflow.js instead of the meitovexflow source files, so you have to build the script every time you change and test something. Do you think it would be good to change these references? (I think it could be helpful, but it's not necessary, since everybody can work with his own modified test files in a separate folder.)
Sometimes, I find it useful to change VexFlow's behaviour by temporarily overriding properties. If there are overrides which should be permanent, do you think it would be a good idea to add a file vexflow-overrides.js (or similar) to contain such overrides? I think that could be more lucid than modifying the VexFlow source code.

[raffazizzi]

I like the idea of including VexFlow sources instead of the minified version - the bower package contains them. Though be careful because the order in which the (many) source files are loaded counts.

I would avoid pushing a vexflow-overrides.js file to the repo - that can easily live on your clone, while others may choose a different way of debugging/developing their code.

[aerhard]

ok, sounds good, I'll do it this way

[zolaemil]

Yeah, I included source files in the tests instead of minified in order to have more informative error messages. I also like the idea of including VexFlow source!

I think it would be great to find a way so when one checks out the library it comes with all the dependences hooked up correctly (i.e. one doesn't need to edit any file in order to run the tests) but in the meantime allow us to hook up to different sources without committing those changes back to the repo.

Maybe git update-index --assume-unchanged would help achieving this?

[zolaemil]

Re vexflow-overrides.js, I think we'd generally like to stick to the main VexFlow branch, so if you have permanent VexFlow changes in there, I am not sure if committing this file to the main branch would be a good idea.

In fact, thinking of this just now, if we need a permanent change in VexFlow then we should probably fork VexFlow and fork MEI2VF and keep it separate until the change gets merged back into the main VexFlow branch, or keep them separate forever.

You can still receive upstream changes in both the VexFlow and MEI2VF fork, and send updates that don't depend on the custom feature.

Otherwise we'd risk losing track of what exact versions we depend on. Does this make sense at all?

[raffazizzi]

There's no need to include VexFlow's source (or compiled) and push it to the repo: Bower takes care of fetching VexFlow sources and compiled file from the official repository when MEI2VF is installed. The test files can point to the standard bower folder structure (as they do now) to make the tests work out of the box.

Then I think you bring up another issue: should we fork VexFlow to include our own changes and make MEI2VF dependent on the fork?

I'm not sure. I can be convinced otherwise, but I think it would be best if the front-facing repository only used official releases. This doesn't stop us from including special changes in MEI2VF as long as there is a clean fallback to standard VexFlow. If one wants to use a special version of VexFlow, say from their own fork, I'd either link it locally or add it to bower.json in my clone/fork.

[zolaemil]

I think it would be best if the front-facing repository only used official releases.

I think we are on the same page with this. And you're right, the best practice may be to implement a fall-back to standard VexFlow for each custom-change. This eliminates the need of forking. My argument concerned cases when there's no such fallback.

Let's assume, one decides to use a custom VexFlow for whatever reason. No matter how it's done (be it through bower.json or any other way of 'linking locally') it will be a local change. Is there an elegant way of maintaining this local change - i.e. not committing it to the repo, but still keeping your index clean? It seemed to me that git update-index --assume-unchanged could come in handy. (Since .gitignore and .git/info/exclude are out of question, since if you add bower.json into them, they won't be tracked at all)

[aerhard]

I'd like to agree, too, with one addition / question: I think it would be important to ensure that MEI2VF is fully working at any time, even if there are changes to VexFlow. Would it be best to provide a reference to a specific revision of VexFlow? This way, you could be sure that everything will be working the same way even if VexFlow changes.

[raffazizzi]

One can set a dependency to a specif release. For example in bower.json we have:

"jquery": "~2.1.0" 

which means that bower will install any version of jquery after 2.1.0. But one can restrict bower to a specific version with #:

"jquery": "#2.1.0" 

Unfortunately VexFlow doesn't have any tagged releases on GitHub, so we can't point to a specific version, AFAIK.

[zolaemil]

We can perhaps request one? Or fork and create a tag there?

2014-04-29 1:44 GMT+01:00 Raffaele Viglianti [email protected]:

One can set a dependency to a specif release. For example in bower.json we
have:

"jquery": "~2.1.0"

which means that bower will install any version of jquery after 2.1.0. But
one can restrict bower to a specific version with #:

"jquery": "#2.1.0"

Unfortunately VexFlow doesn't have any tagged releases on GitHub, so we
can't point to a specific version, AFAIK.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-41631439
.

[raffazizzi]

Ok, requested. Let's see how that goes: 0xfe/vexflow#214