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:

basic_picture_puppet_structure

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:

puppet_structure

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:

librarian_notification
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:

install_dependencies_output

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:

mod1_ngnix

mod2_apache

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

navigation

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.

Cheers!


Your RubyMine Team

 

This entry was posted in Announcement, Feature and tagged , , . Bookmark the permalink.

17 Responses to RubyMine 2017.1 EAP: Puppet Project Structure

  1. Karl says:

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

    Keep up the fantastic work guys!

    • Artem Sarkisov says:

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

      • Karl says:

        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…

  2. Andrey says:

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

  3. Nick Miller says:

    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)

    • Artem Sarkisov says:

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

    • Valentin Fondaratov says:

      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.

      • Joseph Oaks says:

        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.

      • David Hollinger III says:

        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. Evgeny Piven says:

    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. Pingback: RubyMine 2017.1 EAP 8: Puppet Module Generation, Docker Support, and more | RubyMine Blog

  6. John says:

    Hi!
    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!
    John

  7. Pingback: Primeiros passos com o Puppet – Aécio Pires

Leave a Reply

Your email address will not be published. Required fields are marked *