Features News

RubyMine 2017.1 EAP: Puppet Project Structure

Hi all,

We’re glad to bring out RubyMine 2017.1 EAP (171.2014.20) containing both new features and significant bug fixes. In this post we’d like to highlight a new feature for Puppet: Puppet Project Structure.

Puppet Project Structure

In the recently released RubyMine 2016.3, we announced more intelligent Puppet support, which provides better code completion and navigation along with other fundamental capabilities. But in this update, we think we have finally made a decent tool for developing Puppet modules, which are the most popular approach to Puppet development:


If you use Puppet for your development operations, you are likely to deal with lots of interdependent modules and/or environments. Each module uses its own resources and classes, or, simply put, files that should be installed for every module in your project. This probably implies downloading these modules to your project and configuring them manually. Bearing this in mind, we have implemented a new project structure that allows you to work with Puppet projects in an intelligent fashion, right inside IDE:


Here’s how it works:

First of all, open or create a Puppet project.

If you don’t have the librarian-puppet gem installed, the IDE will notify you and run the installation in the background:

Starting with this EAP, RubyMine can find all modules/environments in the project automatically, based on dependencies files, and update the project structure if any has changed. Even if the IDE fails to update your project structure after installing additional modules into the project using the terminal, you can manually rescan the directory for modules or environments by using Scan for modules and environments from the context menu.

You’ve placed your modules and specified dependencies in metadata.json and, optionally, Puppetfile for modules, and/or Puppetfile for environments. Now simply right-click on any file or directory inside the module or environment to open context menu, and then click Install dependencies:


Now you can see the installed modules in the .dependencies subdir for modules or modules subdir for environments.

What is important here is that the navigation and completion for each module will work in strict accordance with dependencies. For example, if you are editing one module depending on puppetlabs-nginx, and another module depending on puppetlabs-apache, then you’ll see either nginx or apache in completion:



The same logic applies to navigation actions like Go to declaration, Find usages, and so on:


Important! This EAP cannot handle dependencies versions. If two modules in your project depend on the same module with different versions and you’ve installed dependencies for both of them, navigation and completion may work wrong (resolve/complete from an incorrect version of dependency).

Another important note is that if some of your modules depend on module A, and you’ve got two copies of this module A (e.g. one in project root, and another in .dependencies directory), completion and resolve will work with the one in the project root. This has been done so that you can simultaneously work on a module and its dependency in the same project.

Download the newest EAP and share your feedback. Please post your comments below, and report any feature and bug requests to our tracker.

UPD please see also this post for new improvements for Puppet.


Your RubyMine Team


Comments below can no longer be edited.

15 Responses to RubyMine 2017.1 EAP: Puppet Project Structure

  1. Avatar

    Karl says:

    January 5, 2017

    Now we just need to similar work for Ansible and Chef, but this is seriously cool…

    Keep up the fantastic work guys!

    • Avatar

      Artem Sarkisov says:

      January 5, 2017

      Thank you very much, Karl! Do you usually use all three (Puppet, Ansible, Chef) for your work?

      • Avatar

        Karl says:

        January 6, 2017

        I’ve dabbed in Puppet and Chef, but I use Ansible soo much now it’s now even a joke.

        I’ve even become the owner/maintainer of 18 of my own roles over the past 24 months, and I can assure you there isn’t a helpful product available other than official documentation…

        • Avatar

          Artem Sarkisov says:

          January 8, 2017

          Huh, interesting. Thanks for your insight!

  2. Avatar

    Andrey says:

    January 10, 2017

    Something strange happened with fonts. They has become thinner and smaller on same font sizes compared with version RM 2016

  3. Avatar

    Nick Miller says:

    January 12, 2017

    I implore your team to read the [puppetlabs_spec_helpers documentation](https://github.com/puppetlabs/puppetlabs_spec_helper). particularly the section on the [.fixtures.yaml](https://github.com/puppetlabs/puppetlabs_spec_helper#using-fixtures).

    This is how the community as I know it develops on modules, not with librarian-puppet and the metadata file.

    (plus, the metadata file only takes care of immediate dependencies)

    • Avatar

      Artem Sarkisov says:

      January 13, 2017

      Thank you very much for your comments, Nick! I’ve addressed this to our dev team.

    • Avatar

      Valentin Fondaratov says:

      January 13, 2017

      Hi Nick,

      Thanks for the reference! However looking at https://docs.puppet.com/guides/module_guides/bgtm.html#d-dependencies, I see that both ways (`metadata.json` and `.fixtures.yml`) are used to store dependencies; is there any history behind such duplication to read about? AFAIU `metadata.json` dependencies is a must to be specified when uploading the modules to Puppet Forge (however even some puppetlabs modules “ignore” that a little). Also `puppet module install`, librarian-puppet and other dependency-tacking tools work well with transitive deps. Actually that’s why we use librarian to solve the task instead of us 🙂
      It’s likely that we are missing something so if you have any comments on that we’ll be glad to learn.

      • Avatar

        Joseph Oaks says:

        January 18, 2017

        The 2 files represent 2 different needs. The metadata.json is used by the puppet forge and other subsystems for important information about the module. The .fixtures.yml file on the other hand is used for providing dependent modules for testing your module which upon running say rake spec will look at the .fixtures.yml and download all dependencies.

      • Avatar

        David Hollinger III says:

        January 26, 2017

        The .fixtures.yml file would probably be better for use with resolving puppet dependencies in Rubymine as it can handle Git urls whereas the metadata.json file will only download from the forge.

        It’s a bit wonky, as the deps need to be in both files since metadata.json is used as the source for what modules are dependent, but only the .fixtures.yml file can handle non-forge dependencies

  4. Avatar

    Evgeny Piven says:

    January 28, 2017

    Hey, guys! Awesome work on the Puppet module. This is the preferable way for me to work with our Puppet code.
    But I couldn’t help wondering – are there any plans to support EPP templates?

  5. Avatar

    John says:

    March 27, 2017

    I have question regarding new puppet’s “Install dependencies for environment” in RubyMine. I installed latest RubyMine 2017.1 , Ruby, added SDK and installed missing gems.
    When I now run “Install dependencies(right click on project->)”, I am getting NoMethodError:

    [Librarian] Resolving puppetlabs-apache (= 1.11.0)
    [Librarian] Checking manifests
    C:/Ruby22-x64/lib/ruby/gems/2.2.0/gems/puppet_forge-2.2.3/lib/puppet_forge/v3/base.rb:24:in `orm_resp_item’: undefined method `each’ for “”:String (NoMethodError)

    I bought subscription and really like RubyMine and wish to use all features of this amazing IDE. Any help?

    Many thanks!

Discover more