ericfranz commented on pull request #265: URL: https://github.com/apache/airavata/pull/265#issuecomment-714734200
Some suggestions on preparing this for gem publishing to https://rubygems.org/. Add these to the .gitignore and don't version the Gemfile.lock: ``` Gemfile.lock .ruby-version .ruby-gemset ``` In a tmp directory, if you do `bundle gem airavata` you can see the default gem scaffolding that is created. That is close to the process I used with the https://github.com/osc/ood_core gem. You could actually do that and copy some of the files over. If you do that, some things you will notice: 1. the Gemfile won't have any extra dependencies, the gemspec will have them all defined as either dev or runtime dependencies; thrift would become a runtime dependency 2. there is a lib/airavata.rb file that just has the `module Airavata` and a bunch of require statements at the top for all the code under the airavata directory. I think that you can get by with doing `require "airavata/airavata"` for requiring the lib/airavata/airavata.rb` file that is generated from your build process 3. you can leave version string in the gemspec or have a version file like the convention used by the scaffolding. I think the benefit of the latter is that when using the gem I can do `Airavata::VERSION` to get the version of the library I'm using programmatically, so that is nice. 4. That means that the gem version needs to [follow semantic versioning ](https://guides.rubygems.org/patterns/#semantic-versioning) and the version string of this gem should change every time you publish a new version. 5. Not sure about providing a link back to the source code for a particular gem. I now realize that with ood_core i'm not actually doing that, though with ood_core the git tags are the almost the same as the version string (`OodCore::VERSION` is `0.14.0` and the github tag is `v0.14.0`. Rails doesn't use homepage but a separate source_code_uri though you could just use homepage - really up to you. But you can see how that works when a gem is a subdirectory of a repo: https://github.com/rails/rails/blob/v6.0.3.4/activesupport/activesupport.gemspec#L30. I don't know how you do that with the python sdk but would be curious to know your strategy for linking to the corresponding code in the repo. Would you create a special git tag for the entire airavata repo to reference when the new gem version is created? Or when pushing a new version of the gem, would the version match the version of Airavata itself? 5. You could have the Homepage be the source code directory at the master branch Main guides are https://guides.rubygems.org/make-your-own-gem/ and https://guides.rubygems.org/patterns/. You have to get accounts on rubygems.org and then if you are the first to push the gem you are the owner and then you can add owners of the gem alongside yourself. After you are done setting things you, you can test your gem by cd-ing to the directory and running the command `bundle console`. That uses Bundler to "Start an interactive Ruby console session in the context of the current bundle". A second way to test is to use it in another app. You can have that app's Gemfile specify the `gem "airavata", path: "/path/to/your/gem/dir"` to load that gem from the file system. Let me know how I can help. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
