Installation fails since 1.0.20150318015654 about common-workflow-language HOT 13 CLOSED

Same thing here.

from common-workflow-language.

I had to go back to this commit: f1cfee1 in order to remove the error (not a solution as it breaks other functionality)

from common-workflow-language.

A clone at this commit 6dc4889 seems to work for me?

from common-workflow-language.

Can confirm seandavi's results, although actually running cwltool on an example tool/job is giving me subprocess.py errors.

cwltool wc2-tool.cwl wc-job.json 

gives me

Traceback (most recent call last):
  File "/Users/Jvivian/anaconda/bin/cwltool", line 9, in <module>
    load_entry_point('cwltool==1.0.20150318015654', 'console_scripts', 'cwltool')()
  File "/Users/Jvivian/anaconda/lib/python2.7/site-packages/cwltool-1.0.20150318015654-py2.7.egg/cwltool/main.py", line 72, in main
    (outdir, runjob) = job.run(dry_run=args.dry_run, pull_image=(not args.no_pull), outdir=args.outdir)
  File "/Users/Jvivian/anaconda/lib/python2.7/site-packages/cwltool-1.0.20150318015654-py2.7.egg/cwltool/job.py", line 126, in run
    return (outdir, self.collect_outputs(outdir))
  File "/Users/Jvivian/anaconda/lib/python2.7/site-packages/cwltool-1.0.20150318015654-py2.7.egg/cwltool/draft2tool.py", line 324, in collect_output_ports
    ret = {port["id"][1:]: self.collect_output(port, builder, outdir) for port in ports}
  File "/Users/Jvivian/anaconda/lib/python2.7/site-packages/cwltool-1.0.20150318015654-py2.7.egg/cwltool/draft2tool.py", line 324, in <dictcomp>
    ret = {port["id"][1:]: self.collect_output(port, builder, outdir) for port in ports}
  File "/Users/Jvivian/anaconda/lib/python2.7/site-packages/cwltool-1.0.20150318015654-py2.7.egg/cwltool/draft2tool.py", line 357, in collect_output
    r = builder.do_eval(binding["valueFrom"], r)
  File "/Users/Jvivian/anaconda/lib/python2.7/site-packages/cwltool-1.0.20150318015654-py2.7.egg/cwltool/draft2tool.py", line 39, in do_eval
    return self.jseval(ex["value"], context)
  File "/Users/Jvivian/anaconda/lib/python2.7/site-packages/cwltool-1.0.20150318015654-py2.7.egg/cwltool/draft2tool.py", line 33, in jseval
    return sandboxjs.execjs(exp, "var $job = %s; var $self = %s; %s" % (json.dumps(self.job), json.dumps(context), self.jslib))
  File "/Users/Jvivian/anaconda/lib/python2.7/site-packages/cwltool-1.0.20150318015654-py2.7.egg/cwltool/sandboxjs.py", line 9, in execjs
    nodejs = subprocess.Popen(["nodejs"], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
  File "/Users/Jvivian/anaconda/lib/python2.7/subprocess.py", line 710, in __init__
    errread, errwrite)
  File "/Users/Jvivian/anaconda/lib/python2.7/subprocess.py", line 1335, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

from common-workflow-language.

[off-topic] Is there a formal testing process/CI process in place? Is it worth opening an issue to create one?

from common-workflow-language.

I believe the problem is that package-data in setup.py isn't being included. I will look at that tomorrow.

Regarding setting up a CI/testing server, yes, please create a separate issue for that.

from common-workflow-language.

Also, would it be possible to tag releases in git when they are pushed to PyPi?

from common-workflow-language.

The packages are already built and pushed automatically. The timestamp on the package version is the timestamp of the git commit. It would be ineffective to tag each release because nearly every commit to master results in a new package on PyPi.

I believe I fixed the problem of schemas not being included in the source dist package, unfortunately, I seem to be getting different results running "python setup.py sdist" on my workstation (the schema files are included as intended) compared to the CI server which actually builds and uploads to PyPi (where the schema files are being excluded). I will investigate further.

from common-workflow-language.

Yeah, the package name contains the commit but I was referring to Git tags. Isn't it pretty much standard these days to tag your releases in git? It certainly would have made it easier for us to revert to the previous release via the git clone && git checkout && easy_install . procedure if only the previous release been tagged in git.

from common-workflow-language.

Hi @hannes-ucsc, what I mean is that with rolling release/automatic package upload from master, if every package were tagged automatically you would end up with git tags dropdown with 132 entries, so you don't get any benefit from browsing tags compared to just browsing commit history.

At some point we will probably start making actual stable releases with manually assigned semantic versions and moving towards a more stable branch/merge development flow, but we are not quite there yet.

I'm happy to discuss this further if you want to open a ticket specifically about versioning, or take it to wider community on the mailing list.

from common-workflow-language.

I think this is fixed as of 3bb8b95 (cwltool-1.0.20150324203244), can you verify?

from common-workflow-language.

Verified.

from common-workflow-language.

... for cwltool-1.0.20150324211351 as well as cwltool-1.0.20150324203244

from common-workflow-language.