by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Tony Bargnesi
@abargnesi
@all Added a changelog for belmgr in preparation for the 0.2.0 release.
These are a must! Just checkout bel.rb changelog.
Nick Bargnesi
@nbargnesi
Definitely a must, +1 there
A dozen IPAs :beer: to whoever comes up with a good lightweight automation for changelog generation too. To be fair, IPAs are gross so this isn't a significant incentive.
Tony Bargnesi
@abargnesi
:)
I think automation can be part of it, but I like interpreting the changes for the users of the project.
It can be a pain though, and it's usually after the fact.
I've seen some uses of structured git commits to that end.
Tony Bargnesi
@abargnesi
@nbargnesi Remember the desire to release the built belmgr app? It seems you can do it with BASE_URL=http://localhost:8080/api gulp build export.
Serving the export/ directory provides a really snappy search page.
But the welcome and search page are the only routes available. The other pages 404.
@wshayes Any thoughts?
Nick Bargnesi
@nbargnesi
Yes, and releasing a built app would make things simpler. If we default BASE_URL to window.location scheme + host + '/api' and support changing it dynamically through the interface, it will be doable. Relying on BASE_URL during the build process is too fragile to support the build/export artifacts.
Tony Bargnesi
@abargnesi
That's a great feature, but I think there is value releasing a built web application that defaults to http://localhost:9292/api. Out-of-the-box experience with belmgr and openbel-api.
More eyeballs
Ok I was able to run it fully by piecing together artifacts of gulp build and gulp export. That should work.
Nick Bargnesi
@nbargnesi
Okay then, just include the first part with reasonable BASE_URL defaults. Could we support an out-of-the-box experience with a single gem approach? E.g., instaling openbel-platform would bring in openbel-api and a belmgr built with those defaults.
I think I see what you're saying. API defaults to http://localhost:9292/api now, defaulting the belmgr build BASE_URL to the same would give the out-of-the-box experience. Yes, that works. As long as no one tries to use a build artifact for anything other than that deployment.
Tony Bargnesi
@abargnesi
I think so. We can certainly package up the web application files in a single sub directory. Then we could serve them up through sinatra as static files.
At a different path.
Maybe belmgr could read the base url from the OpenBEL API configuration file. Use the configuration file as a central point of configuration data.
Puma could be setup with this configuration as well. That would get us towards needing only a rack-compliant http server once we can run on other rubies.
Nick Bargnesi
@nbargnesi
Then let's build artifacts for stable branches and releases on the build server. We'll publish the release artifacts to GitHub too. That supports the out-of-the-box experience and gem, Puma, etc, can use them directly. We do still need a reasonable default BASE_URL if none exists though. And the window.location scheme works well for this. If this sounds good, I'll write it up.
Tony Bargnesi
@abargnesi
Great idea! Sounds good to me.
I'll publish the build that I have now for 0.2.0. And I'll log a bug for "gulp build export" usage.
Nick Bargnesi
@nbargnesi
Can I link this discussion to the issue?
Tony Bargnesi
@abargnesi
No, don't think so. Gitter's API is mostly crap.
Paste it in?
Nick Bargnesi
@nbargnesi
Will do.
Woohoo! The timestamp to the right can serve as a link.
+1 gitter
Tony Bargnesi
@abargnesi
Super cool and impressive.
William Hayes
@wshayes
:point_up: March 16, 2016 9:58 AM https://www.linkedin.com/groups/4257384/members/admins Ted and Diane are the group admins. I’ll contact Ted and ask for you and I to be added.
Nick Bargnesi
@nbargnesi
Nice use of linking there :)
Tony Bargnesi
@abargnesi
Thanks william, thanks for the conversation reminder ;)
Nick Bargnesi
@nbargnesi
@abargnesi OpenBEL/belmgr#52
Tony Bargnesi
@abargnesi
@nbargnesi Attempted class inheritance comparison in OpenBEL/parsers@db85d81
PTAL
Tony Bargnesi
@abargnesi
@all I posted an early bel_parser (version 1.0.0.alpha.1) to RubyGems. https://rubygems.org/gems/bel_parser
Tony Bargnesi
@abargnesi
Install with gem install bel_parser --pre. You can then type BEL 2.0 terms into the console using the bel2_termcheck command.
Tony Bargnesi
@abargnesi
@wshayes Looked into PSI-MOD protein modification ontology (http://psidev.cvs.sourceforge.net/viewvc/psidev/psi/mod/data/PSI-MOD.obo.xml). The root term is named "protein modification".
Seems to jive with how you named it.
William Hayes
@wshayes
Looking at the RDF Schema tutorial https://www.w3.org/2007/02/turtle/primer/#L3514
Based on the RDF Schema notes from the Primer - the following indicates hasVariant’s subject must be an instance satisfying all of the listed Abundances rather that one of the listed Abundances. It also indicates that the RDF Schema’s functionality is based on how it is used. So @abargnesi - would you rather have the listed options as below or just list bel:Abundance even though CompositeAbundance can’t be used with hasVariant?
belv:hasVariant rdf:type rdf:Property ;
    rdfs:domain belv:GeneAbundance ;
    rdfs:domain belv:RNAAbundance ;
    rdfs:domain belv:MicroRNAAbundance ;
    rdfs:domain belv:ProteinAbundance .
Nick Bargnesi
@nbargnesi
@abargnesi I'd like to get your feedback on nbargnesi/bel-parser@2df027c when possible