Create a developer paclet named PacletDeployExample.

By default, creating a developer paclet causes the session to enter developer mode thereby making the paclet immediately available.

The developer paclet however, is not yet deployable since part of its deployment involves running PacletBuild and this built-in function itself requires at least some documentation to successfully execute.

Typically the process of adding documentation for a paclet's functionality occurs interactively using Documentation tools as part of the paclet's ongoing development. For demonstration purposes here however, mimicking the results of this interactive development can be simulated by adding a single documentation file to the paclet; a file of the type that is normally added automatically during interactive development.

Now, because the paclet contains some documentation it can be built and therefore deployed.

End-users access deployed paclets, not developer paclets so exit developer mode to ensure these are accessible in this environment:

Confirm the deployed paclet's availability in an end-user environment.

Delete the developer paclet.

Remove the installed paclet.

One pathway to releasing a commercial paclet is to first perform a series of standard, local deployments in the main process of establishing the paclet's functionality. When the paclet is ready for prime-time however, a final commercial deployment can be performed including new configurations that might be more appropriate for a paclet's wider distribution. The following sequence provides a framework for such a workflow.

Create a developer paclet named developerCommercialPaclet:

The package becomes immediately available

The definitions of the package's public functions, can now be progressively iterated as the initial definition of FooA is progressively fleshed out.

In concert with fleshing out FooA's functionality, the related documentation can now also be progressively refined, in preparation and as a pre-requisite for, a standard deployment. Usually this documentation is added interactively using Documentation Tools but here it is simulated for demonstration purposes by manually adding a sample FooA documentation page to the paclet.

To assess how the paclet performs in an end-user environment, the paclet can be periodically deployed as a standard deployment before being tested in this environment.

Typically, a deployed paclet contains only the final payloads needed by end-users, unlike the developer paclet which retains other material needed for development (for example, a build folder). But in standard deployments the common payloads are nonetheless similarly expressed including the number and visibility of each paclet's respective kernel files. To observe this, first load the helper package PacletTools`.

Create a function that counts the number of .nb, .m, .wl and .wlt files in a given paclet extension.

Observe that the same number of kernel files appear in both developerCommercialPaclet and standardDeploy.

Observe that the same number of test files appear in both developerCommercialPaclet and standardDeploy.

Create a function that compares the visibility of a paclet's kernel files.

Observe that code from developerCommercialPaclet and standardDeploy are both visible and without difference.

Remove the installed paclet, standardDeploy.

A commercial release differs from a standard release starting by excluding the shipping of developer files not relevant to end-users.

Deploy the paclet in a commercial release

The paclet developerCommercialPaclet was created using the "ClassicNotebook" paclet layout in which .m files are automatically generated from initialization cells arranged by the developer's source .nb notebooks. Since the .m files are what ultimately provide end-users' functionality, the original, source .nb files are not strictly necessary for end-user evaluations and can therefore be omitted in commercial deployments.

Observe that source .nb files present in developerCommercialPaclet have been omitted in the commercialDeploy.

In a similar vein, test files come in two flavours, original "source" .nb test files (optimized for organizing tests) and their .wlt derivatives (optimized for running tests). Since running the .wlt files are what ultimately provides public testing for a package's functions, the source .nb files are not strictly necessary for such usage and hence can be omitted in commercial deployments.

Observe that source .nb test files present in developerCommercialPaclet have been omitted in commercialDeploy.

Note that, if desired, the default behaviour just described can be customized by modifying the "ExcludedFiles" option.

A commercial release can also differ from a standard release by having kernel code obfuscated in order to protect the creator's IP. By default, all kernel code is obfuscated in a commercial release.

Code from the developer paclet remains readable unlike the code deployed in the commercial paclet.

The release date is automatically inserted into the PacletInfo.wl file in commercial deployments.

For commercial deployments, the generated .paclet file is stored not in a build directory (as for standard deployments) but in the developer paclet's release directory.

Remove the installed paclet.

Delete the developer paclet.