Hi @virtualcitymatt ,

FME Packages are intended to include components of related functionality—whether it’s transformers, formats, or web services —making it easier to distribute shared content.

Some of the best practices we consider when creating packages are:

• Flexibility in Contents: Packages can contain one or more transformers, formats, or web services.
• Related Functionality: Packages typically group components that share a common purpose. For example, our rule of thumb is to ask whether they share a common library/API or possibly use a common web connection (e.g., Azure Storage package). Including unrelated transformers in the same Package is not recommended because changes to a transformer may impose Package restrictions that would unnecessarily apply to all transformers within that Package
• Dependencies and Trade-offs: While grouping related transformers/formats/web services together is great for sharing code, it means you’ll need to upgrade all components in the package if one needs an update. However, this approach ensures logical and maintainable grouping.

Hope this helps provide a bit more guidance for using Packages,

Andrea

Perfect, thanks @andreaatsafe .

Good to know it can have multiple transformers etc inside. I’m working on a new FME based product and trying to think about the best method for distribution to customers. I’m torn between just a group of workspaces with embedded code or workspaces plus package with linked transformers. 

I’m thinking about how the package is just a simple way to install all related components. In addition when publishing to FME Flow the package seems to also get published which is an added benefit compared to just CustomTransformers/Formats which require an additional step.