search

XLSForm / pyxform

A Python package to create XForms for ODK Collect.
BSD 2-Clause "Simplified" License
82 stars 136 forks source link

Avoid relying on a compiled JAR file from external PRs #64

Closed dorey closed 6 years ago

dorey commented 8 years ago

So far, external contributions of changes to the ODK validate Jar files have been helpful, but it would be much healthier for the repository to have a different way for the JAR to be compiled (perhaps locally after installation)

dorey commented 7 years ago

I've been assured that we can compile JAR files during the setup.py installation step so that we can avoid committing binaries into the repo.

lognaturel commented 7 years ago

JavaRosa is now published to the maven central repository and included in Java-based tools by gradle. As described in #113 and opendatakit/javarosa#58, it would be great if the dependency could be on JR rather than Validate. Even better if it could be pulled from maven central!

lindsay-stevens commented 6 years ago

This problem is also faced in #167, where we're faced with potentially vendorising a JS project (enketo-validate) into pyxform.

What I suggest is to create a utility / CLI tool that a user can invoke which will download the relevant validator dependencies if they don't already exist.

If everyone is comfortable with it, this download process could be automatic, as part of the setup.py install. On the one hand it might be annoying if you were someone who had no interest in using the validators, but on the other hand not making it automatic would mean a two-step install process for those (the majority?) that are interested in validated XForms.

The ongoing maintenance then would be to update the fetch URL for the validators. This could also be avoided if both odk_validate and enketo-validate publish their latest compiled releases in a way that has a "current" URL that points to the latest version.

For example if both projects uploaded their compiled packages as GitHub release attachments, then the download link can be reliably parsed from the GitHub API, e.g. https://api.github.com/repos/opendatakit/validate/releases/latest returns a JS document where the attachment URLs are populated in the "assets" array. Attaching artifacts to GitHub releases can be automated with Travis & AppVeyor based on git tags too, so that the whole process automagical.

I think this would be in scope for #167 so please let me know if this would be a supported strategy and I'll have a go at implementing it.

MartijnR commented 6 years ago

Thanks. I like this, and combining it with #167 seems fine to me (and I guess, upgrade to ODK Validate 1.8.0 in the same go if it takes the latest). We should leverage your involvement to the max @lindsay-stevens!

Does that sound okay (@yanokwa @ln, others)?

(For some reason https://api.github.com/repos/enketo/enketo-validate/releases/latest is still empty even though there have been 3 releases. Will try to figure out why. https://github.com/enketo/enketo-validate/issues/24) Updated: figured it out and it's working now.

lognaturel commented 6 years ago

Pulling the dependencies as part of setup from the GitHub latest release URL sounds good to me. Validate jars aren’t currently served from there but the latest will be added shortly.

yanokwa commented 6 years ago

This sounds great to me. Thanks for being so thoughtful about this, @lindsay-stevens!

lindsay-stevens commented 6 years ago

Had a go at this today - downloading stuff is easy enough but getting enketo-validate to run like the odk-validate jar does has proven to be a little tricky but not impossible - see https://github.com/enketo/enketo-validate/issues/2

lindsay-stevens commented 6 years ago

Hi all - a PR for this is ready at #171 if someone could please review / approve.

lindsay-stevens commented 6 years ago

I think this is now fully addressed in #171 - it shouldn't be necessary to commit ODK_Validate updates in future since the latest version can be grabbed with the new updater script.