by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Nick Bargnesi
@nbargnesi
commented and merged
William Hayes
@wshayes
I’d prefer to handle configuration in a different way. I’ll probably back this out after deploying an updated configuration system.
Tony Bargnesi
@abargnesi
sounds good
Nick Bargnesi
@nbargnesi
no need to back it out once we have something better in place (i.e., git revert?)
Tony Bargnesi
@abargnesi
I had the sense BASE_URL/PUBMED_URL would be obsolete and removed after a new configuration system is in place
William Hayes
@wshayes
@abargnesi Yes - I prefer to put a new system in place first :)
William Hayes
@wshayes
Or not - can’t pull Env variables from a Javascript app. Duh! and aarrrgghhh!!!
Nick Bargnesi
@nbargnesi
@abargnesi opened PR 101
Tony Bargnesi
@abargnesi
@nbargnesi Commented on the "secret" configuration. Otherwise looks great.
Nick Bargnesi
@nbargnesi
@abargnesi updated PR with comments for each setting, thanks for the :star:
Tony Bargnesi
@abargnesi
Thanks. Totally missed the auth middleware regarding secret.
Tony Bargnesi
@abargnesi
@juliakozlovsky Fix for OpenBEL/bel.rb#111 dropped on the next branch. This includes the work I mentioned in our earlier skype conversation with Alexandr. The commit is OpenBEL/bel.rb@d9ce98c.
We're planning to push this out in a bel 0.6.0 version today. We should then be able to integrate Alexandr's work on OpenBEL/bel.rb#92 on 0.6.0 when he's ready.
Tony Bargnesi
@abargnesi
@/all bel.rb 0.6.0 is released (https://github.com/OpenBEL/bel.rb/releases/tag/0.6.0).
sbagewadi
@sbagewadi
Tony: could you please send me the links we discussed about last week. This should include the tutorial for adding new annotations. Also, could you point me to the latest BEL tutorial documentation. http://wiki.openbel.org/display/BLD/BEL+Information+PDFs this is 2011 version. Do you have a latest one?
Tony Bargnesi
@abargnesi
@sbagewadi Sure, the links were added to the 2016-03-08 meeting notes.
I don't think we have much of a tutorial at the moment though @kellymccann91 is working on it. You can refer to the BEL 1.0 reference on the wiki or the official specification.
Tony Bargnesi
@abargnesi
@all Anyone know who manages the OpenBEL linkedin community page?
William Hayes
@wshayes
I will check when I get back to the office.
Tony Bargnesi
@abargnesi
thanks!
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?