Managing Policies for Packages and Projects
Introduction
Admins can create new policies with rules that can block or allow packages (and versions) based on the version number and (in the future) other arbitrary metadata like package version licenses, authors, and so on.
The reason we have created this feature is because organizations need to be able to block certain packages and/or versions for legal, compliance, security, or internal compliance reasons and this is one way we help address that need. Package policies enhance both the package server and Julia instances because they change both whether the server will allow a package to be downloaded and also how Julia itself resolves package versions.
Although only admins can create and edit policies, any member of a project can choose the policies for it.
Important Note About Policy Behavior
It is very important to understand that a project’s policies only specify how to block packages. If any of a project’s policies block a package version, then it is blocked for the project; there is no way for a project to override a block from one of its policies. So if you were to create, for example, a policy that blocks all packages except for a specific package, any project that used this policy would not have access to the blocked packages at all.
Please note that projects that block most packages can cause a large delay in package synchronization, so it’s normally better to avoid such policies.
Creating and Editing Policies
To create a policy, go to the Policies page in the Admin section at the bottom of the left menu bar and click 'Policies'.
Click on New Package Policy button to create a new package policy that blocks packages or versions of packages.
New policies start out not blocking all packages by default. You can change the default behavior to Block by default but it’s important to note that a policy that blocks most packages can cause a large delay in package synchronization, so it’s normally better to avoid such policies.
Once you have chosen all of the packages to allow or block, click ”Create” to create the policy. In this example, I have choose to block CSV pakages.
The packages and versions you specify in the rules list are exceptions to the default blocking behavior of the policy. If Block by default is not checked, the packages and versions you specify indicate what to block. If Block by default is checked, the packages and versions you specify indicate what not to block.
If you want to specify just a package, all you need to do is type part of the name and select it from the list. If you want to specify certain versions of a package, add a package rule like before and enter a pattern of comma-separated versions and version ranges in the item for the rule. Versions can include major; major and minor; or major, minor, and patch numbers, with unspecified numbers matching anything, e.g. the pattern 1.2 matches any versions starting with 1.2, such as 1.2.0 and 1.2.9. Version ranges are two version patterns separated by a dash (-).
IMPORTANT: Since 1 matches any version starting with 1, the range 1.2-1 matches, perhaps unintuitively, any version from 1.2.0 up to, but not including, 2.0.0 and the range 1.2-2 matches any version from 1.2.0 up to but not including 3.0.0.
NOTE: the pattern 1.2 by itself only matches versions beginning with 1.2 unlike within the compat section of Project.toml where it would have a different meaning.
If you want to make a license policy, click “New license policy” to create it, select whether you want to block by default, and choose the licenses for which you want to make rules.
As with package policies, the license rules you choose will be exceptions to the default blocking behavior. If the policy does not block by default, the license rules specify which licenses will be blocked. If it blocks by default, the license rules specify which licenses not to block.
Once you have created all of the package or license rules you need, click ”Create” to create the policy.
After a policy is created, you can click “Edit” on the policy to make changes using the policy editor above that you use to create policies.
Managing Project Policies
Each project can have a set of policies. When project code runs, it uses the project’s “view” of the JuliaHub instance’s registries which contain only those package versions not blocked by any of the project’s policies. If any of a project’s policies blocks a version, it is absent from the project’s view of the registries.
To set the policies for a project, view the project and click the “Manage” button, then select “Manage Policies”.
Clicking this brings up the “Manage Policies” view, which shows the project’s policies. You can change them by clicking “+ Select policies” to show the policy selector.
Once you are done adding and/or removing policies, click ‘Save’.
You will see the successful message of the updated policy.
You will be able to check or edit your policy now.
You can test your policy in two ways: by checking compliance on your JuliaHub site or by using the Julia package manager in the IDE.
To check compliance, go to your project and select “Check compliance” in the “Manage” menu.
If your project is not compliant, the “Check compliance” item will show a red “X”,
A list of non-compliant files will appear,
And clicking on an item in the list will show the infractions.
You can also interact with policies by launching an IDE in your project and then connecting to it when it’s ready.
Once the IDE is running, if you go to the REPL and try to add a package excluded by your project’s policy, it should fail.
