Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-5281

Reserve (and deprecate) the use of 'environment' as a module name

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Accepted
    • Priority: Normal
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Docs
    • Template:
    • Sub-team:
    • Team:
      Froyo
    • Release Notes:
      Bug Fix
    • Release Notes Summary:
      The 4.x release reserved the namespace 'environment' without doing a technical deprecation/warning if used as the name of the module. The documentation is now updated with this information.

      Description

      With the introduction of the 4.x function API came the ability to define functions at the environment level using the symbolic namespace environment::. The rationale behind using a symbolic name space is that environments often change name as they are developed and tested and thus it becomes very impractical to having to rename things inside of the environment based on the name it is made available under.

      We expect that reserving this name should not cause much trouble. There is no module on the forge with this name, and for any user that has such a module, they should very seriously (even without reserving it) consider it to maintain sane since 'environment' is already an overloaded concept.

      At the moment, only the 4.x API based function loader is capable of using this namespace. The long term intent is to also base loading of other entities on the 4.x loader infrastructure. When that is done, it could also be possible to load other things than functions from the environment.

      It is also possible that we may start treating an environment more like a module in the future.

      Technically, we should add a deprecation warning if the system finds a module on the modulepath that is named 'environment' (in the 4.x series). And for the next major we should error on such a module.

      We can also add validation to the module meta data to reduce the risk of someone authoring a new module with the reserved name.

      This ticket is to capture the need to document this, and to design (and log additional tickets) once we have decided exactly where and how the validation and warnings should take place.

        Attachments

          Activity

            People

            Assignee:
            Unassigned
            Reporter:
            henrik.lindberg Henrik Lindberg
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:

                Zendesk Support