> [!NOTE]
> This is a fork by Gemma Analytics of the original Permifrost project. The motivation is to use it in tandem with [tundri](https://github.com/Gemma-Analytics/tundri).
# `permifrost`
We welcome contributions, so please feel free to submit MRs or [issues](https://gitlab.com/gitlab-data/permifrost/-/issues/new) if you'd like to help in any way. To get started with contributions read the [Contributing](#contributing) section at the bottom of this README to get started.
## Installation
Install the most stable version using the following command:
```
pip install permifrost
```
If you would like to work with the most up-to-date functionality in permifrost install directly from GitLab using the following command:
```
pip install git+https://gitlab.com/gitlab-data/permifrost.git
```
## Usage
Use this command to check and manage the permissions of a Snowflake account.
```bash
permifrost [-v] run <spec_file> [--role] [--dry] [--diff] [--user] [--ignore-memberships]
```
```shell
#> permifrost run --help
Usage: permifrost run [OPTIONS] SPEC
Grant the permissions provided in the provided specification file for
specific users and roles
Options:
--dry Do not actually run, just check.
--diff Show full diff, both new and existing permissions, use with -v.
--role TEXT Run grants for specific roles. Usage: --role testrole --role
testrole2.
--user TEXT Run grants for specific users. Usage: --user testuser --user
testuser2.
--ignore-memberships Do not handle role membership grants/revokes
--help Show this message and exit.
```
Use this utility command to run the SnowFlake specification loader to confirm that your `roles.yml` file is valid.
```bash
permifrost [-v] spec-test <spec_file> [--role] [--user] [--ignore-memberships]
```
```shell
#> permifrost spec-test --help
Usage: permifrost spec-test [OPTIONS] SPEC
Load SnowFlake spec based on the roles.yml provided. CLI use only for confirming specifications are valid.
Options:
--role TEXT Run grants for specific roles. Usage: --role testrole
--role testrole2.
--user TEXT Run grants for specific users. Usage: --user testuser
--user testuser2.
--ignore-memberships Do not handle role membership grants/revokes
--run-list TEXT Run grants for specific users. Usage: --user testuser
--user testuser2.
--help Show this message and exit.
```
Given the parameters to connect to a Snowflake account and a YAML file (a
"spec") representing the desired database configuration, this command makes sure
that the configuration of that database matches the spec. If there are
differences, it will return the sql grant and revoke commands required to make
it match the spec. If there are additional permissions set in the database this
command will create the necessary revoke commands with the exception of:
- Object Ownership
- Warehouse Privileges
Furthermore, if you are using the recommended role of `SECURITYADMIN`, `ALTER USER ...` commands will fail on users that are owned by `ACCOUNTADMIN`. In these circumstances, it is highly recommended to log into the Snowflake instance and update ownership of all users to belong to `USERADMIN` as per Snowflake recommended best practices.
Lastly, note that the default roles cannot have their role hierarchies modified. As such, any `GRANT ROLE <default role> TO ROLE <default role>;` will be excluded from the permission set generated by Permifrost.
For example:
```yaml
...
roles:
public:
member_of:
- useradmin
securityadmin:
member_of:
- useradmin
...
```
Both of the above relationships will be skipped as this attempts to modify a default Snowflake permission structure which would generate an error on attempting to implement.
Permifrost is heavily inspired by
[pgbedrock](https://github.com/Squarespace/pgbedrock) which can be used for
managing the permissions in a Postgres database.
## spec_file
The YAML specification file is used to define in a declarative way the
databases, roles, users and warehouses in a Snowflake account, together with the
permissions for databases, schemas and tables for the same account.
All permissions are abbreviated as `read` or `write` permissions, with
Permifrost generating the proper grants for each type of object. This includes
shared databases which have simpler and more limited permissions than non-shared
databases.
According to the `read` vs. `write` permissions approach, you should be able to
grant granular access like `read` permissions for usage of database and schema
and `write` permissions to insert data into a specific table within that
database and schema.
Please find below the links between Permifrost permissions and Snowflake grants.
| Objects | Permifrost permissions | Snowflake grants |
|-----------|------------------------|---------------------------------------------------------------------------------------------------------------------|
| Databases | read | usage |
| | write | monitor, create schema |
| Schemas | read | usage |
| | write | monitor, create table, create view, create stage, create file format, create sequence, create function, create pipe |
| Table | read | select |
| | write | insert, update, delete, truncate, references |
Tables and views are listed under `tables` and handled properly behind the
scenes.
If `*` is provided as the parameter for tables the grant statement will use the
`ALL <object_type>s in SCHEMA` syntax. It will also grant to future tables and
views. See Snowflake documentation for [`ON
FUTURE`](https://docs.snowflake.net/manuals/sql-reference/sql/grant-privilege.html#optional-parameters)
If a schema name includes an asterisk (prefix or suffix), such as `snowplow_*` or `*_snowplow`, then all schemas
that match this pattern will be included in the grant statement _unless it is
for ownership_, in which case the asterisk is not supported. This can be coupled
with the asterisk for table grants to grant permissions on all tables in all
schemas that match the given pattern. This is useful for date-partitioned
schemas.
All entities must be explicitly referenced. For example, if a permission is
granted to a schema or table then the database must be explicitly referenced for
permissioning as well. Additionally, role membership must be explicit in the
config file. If a role does not have a `member_of` list, it will have all roles
it currently has revoked.
Roles can accept "_" as a role name either alone or nested under the `include`
key. There is optionally an `exclude` key that can be used if `include` is used.
`"_"`will grant membership to all roles defined in the spec. Any roles defined
in`exclude`will be removed from the list defined in`include`.
Objects like warehouses and integrations that only have one permifrost permission type just
needs to be specified in the role (see below).
Objects can have a `meta` dictionary which may contain information that is not relevant for Permifrost's
execution and are ignored by Permifrost itself.
A specification file has the following structure:
```bash
# Databases
databases:
- db_name:
shared: boolean
- db_name:
shared: boolean
owner: role_name
meta:
some_key: some_value
...
... ... ...
# Roles
roles:
- role_name:
warehouses:
- warehouse_name
- warehouse_name
...
member_of:
- role_name
- role_name
...
# or
member_of:
include:
- "*"
exclude:
- role_name
privileges:
databases:
read:
- database_name
- database_name
...
write:
- database_name
- database_name
...
schemas:
read:
- database_name.*
- database_name.schema_name
- database_name.schema_partial_*
- database_name.*_schema_partial
...
write:
- database_name.*
- database_name.schema_name
- database_name.schema_partial_*
- database_name.*_schema_partial
...
tables:
read:
- database_name.*.*
- database_name.schema_name.*
- database_name.schema_partial_*.*
- database_name.*_schema_partial.*
- database_name.schema_name.table_name
...
write:
- database_name.*.*
- database_name.schema_name.*
- database_name.schema_partial_*.*
- database_name.*_schema_partial.*
- database_name.schema_name.table_name
...
owns:
databases:
- database_name
...
schemas:
- database_name.*
- database_name.schema_name
...
tables:
- database_name.*.*
- database_name.schema_name.*
- database_name.schema_name.table_name
...
meta:
some_key: some_value
...
- role_name:
owner: role_name
... ... ...
# Users
# can_login is required the rest of the parameters are optional
# None of the values are validated in Snowflake, hence default_warehouse, default_namespace and default_role
# can contain invalid values
users:
- user_name:
can_login: boolean
member_of:
- role_name
...
has_password: boolean
display_name: string
first_name: string
middle_name: string
last_name: string
email: string
comment: string
default_warehouse: string
default_namespace: string
default_role: string
meta:
some_key: some_value
...
- user_name:
owner: role_name
... ... ...
# Warehouses
# Warehouse sizes are informative and not altered by Permifrost to align with the spec file
warehouses:
- warehouse_name:
size: x-small
meta:
some_key: some_value
...
- warehouse_name:
size: x-small
owner: role_name
... ... ...
# Integrations
# Integration categories are informative and not altered by Permifrost to align with the spec file
integrations:
- integration_name:
category: storage
meta:
some_key: some_value
...
- integration_name:
category: security
owner: role_name
... ... ...
```
For a working example, you can check [the Snowflake specification
file](https://gitlab.com/gitlab-data/permifrost/blob/master/tests/permifrost/specs/snowflake_spec.yml)
that we are using for testing `permifrost permissions`.
Note: The spec file must all be in lowercase.
### Settings
All settings are declared here with their default values and are described
below. These can be added to your spec.yaml file.
```yaml
require-owner: false
```
`require-owner`: Set to true to force having to set the `owner` property on all
objects defined.
## --diff
When this flag is set, a full diff with both new and already granted commands is
returned. Otherwise, only required commands for matching the definitions on the
spec are returned.
## --dry
When this flag is set, the permission queries generated are not actually sent to
the server and run; They are just returned to the user for examining them and
running them manually.
When this flag is not set, the commands will be executed on Snowflake and their
status will be returned and shown on the command line.
## Connection Parameters
The following environmental variables must be available to connect to Snowflake:
```bash
$PERMISSION_BOT_USER
$PERMISSION_BOT_ACCOUNT
$PERMISSION_BOT_WAREHOUSE
```
### Username and Password
To connect using a username and password, also include the following:
```bash
$PERMISSION_BOT_PASSWORD
$PERMISSION_BOT_DATABASE
$PERMISSION_BOT_ROLE
```
Currently, Permifrost assumes you are using the SECURITYADMIN role and will fail
validation if you are not.
### OAuth
To connect using an OAuth token, also include the following:
```bash
$PERMISSION_BOT_OAUTH_TOKEN
```
### External Browser SSO Auth
To connect using an external browser with SSO Auth, also include the following:
```bash
$PERMISSION_BOT_AUTHENTICATOR='externalbrowser'
```
### Key Pair Authentication
Rather than supplying a password or an oauth token, it's possible to connect via
Snowflake's Key Pair authentication by setting the following:
```bash
$PERMISSION_BOT_KEY_PATH
$PERMISSION_BOT_KEY_PASSPHRASE
```
See [Snowflake-sqlalchemy](https://github.com/snowflakedb/snowflake-sqlalchemy#key-pair-authentication-support) for more info.
## Contributing
Contributing to Permifrost is easy, and most commands to do so are available
within the Makefile.
The easiest way to start developing is to run `make initial-setup` to install
all the necessary packages to develop on the project. Next run `make
permifrost` in a second terminal, this will open a shell in a docker container
with the local version of Permifrost installed.
You can now make changes to the files in your editor and it will be reflected in
the commands that you run from the docker shell.
To check code quality prior to committing changes, you can use `make local-lint`.
See the [Makefile](Makefile) for more details.
**WARNINGS**
DO NOT name git branches with forward slashes `/` as the current CI pipeline is
unable to manage names like this. (i.e. `username/feature/feature-name` will
break the CI pipeline so `username.feature.feature-name` should be used
instead)
This project has [pre-commit
hooks](https://github.com/pre-commit/pre-commit-hooks) installed to maintain
the existing code quality. As such, we strongly recommend you use a terminal to
**commit** and **push** code changes. Specifically, avoid using git
integrations on IDEs to make **commits** or **pushes**. **Adding** files
through the IDE git integrations are okay, but do not **commit** through the
IDE. Use the terminal to commit changes because it will show the output of each
of the pre-commit checks to allow you to make changes as needed.
For committing work-in-progress changes use `git commit --no-verify -m "WIP:
<message>"`.
For committing finalized changes, the below workflow will identify errors and allow for easier development:
* Make your changes and `git add <file name(s)>`
* `git commit` to identify/format errors in the changed files
* Repeat the following steps until all checks pass
* `git add <file name(s)>`
* `git commit`
* Add message at the prompt and save/exit the commit file
* When you are ready to push changes to the remote host, run `git push origin <branch name>`. This will perform additional linting/formatting checks.
* Repeat the following steps until all checks pass
* `git push origin <branch name>`
* `git add <file name(s)>`
* `git commit`
* Add message at the prompt and save/exit the commit file
* `git push origin <branch name>` until all checks pass
## Releasing
See the [issue template](https://gitlab.com/gitlab-data/permifrost/-/blob/master/.gitlab/issue_templates/Releasing%20update.md)
for guidance on how to release a new version of this project to PyPi
Raw data
{
"_id": null,
"home_page": "https://github.com/Gemma-Analytics/permifrost",
"name": "gemma.permifrost",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.8",
"maintainer_email": "Gemma Analytics <info@gemmaanalytics.com>",
"keywords": "snowflake, permissions, database, security",
"author": "Gemma Analytics",
"author_email": "Gemma Analytics <info@gemmaanalytics.com>",
"download_url": "https://files.pythonhosted.org/packages/bf/9f/5e7309edb4541e9efbbb28be6696ba733f21f3098abc9f1f93ef2aafcd70/gemma_permifrost-0.1.3.tar.gz",
"platform": null,
"description": "> [!NOTE] \n> This is a fork by Gemma Analytics of the original Permifrost project. The motivation is to use it in tandem with [tundri](https://github.com/Gemma-Analytics/tundri).\n\n# `permifrost`\n\nWe welcome contributions, so please feel free to submit MRs or [issues](https://gitlab.com/gitlab-data/permifrost/-/issues/new) if you'd like to help in any way. To get started with contributions read the [Contributing](#contributing) section at the bottom of this README to get started.\n\n## Installation\n\nInstall the most stable version using the following command:\n\n```\npip install permifrost\n```\n\nIf you would like to work with the most up-to-date functionality in permifrost install directly from GitLab using the following command:\n\n```\npip install git+https://gitlab.com/gitlab-data/permifrost.git\n```\n\n## Usage\n\nUse this command to check and manage the permissions of a Snowflake account.\n\n```bash\npermifrost [-v] run <spec_file> [--role] [--dry] [--diff] [--user] [--ignore-memberships]\n```\n\n```shell\n#> permifrost run --help\nUsage: permifrost run [OPTIONS] SPEC\n\n Grant the permissions provided in the provided specification file for\n specific users and roles\n\nOptions:\n --dry Do not actually run, just check.\n --diff Show full diff, both new and existing permissions, use with -v.\n --role TEXT Run grants for specific roles. Usage: --role testrole --role\n testrole2.\n\n --user TEXT Run grants for specific users. Usage: --user testuser --user\n testuser2.\n\n --ignore-memberships Do not handle role membership grants/revokes\n --help Show this message and exit.\n```\n\nUse this utility command to run the SnowFlake specification loader to confirm that your `roles.yml` file is valid.\n```bash\npermifrost [-v] spec-test <spec_file> [--role] [--user] [--ignore-memberships]\n```\n\n```shell\n#> permifrost spec-test --help\nUsage: permifrost spec-test [OPTIONS] SPEC\n\n Load SnowFlake spec based on the roles.yml provided. CLI use only for confirming specifications are valid.\n\nOptions:\n --role TEXT Run grants for specific roles. Usage: --role testrole\n --role testrole2.\n\n --user TEXT Run grants for specific users. Usage: --user testuser\n --user testuser2.\n\n --ignore-memberships Do not handle role membership grants/revokes\n --run-list TEXT Run grants for specific users. Usage: --user testuser\n --user testuser2.\n\n --help Show this message and exit.\n```\nGiven the parameters to connect to a Snowflake account and a YAML file (a\n\"spec\") representing the desired database configuration, this command makes sure\nthat the configuration of that database matches the spec. If there are\ndifferences, it will return the sql grant and revoke commands required to make\nit match the spec. If there are additional permissions set in the database this\ncommand will create the necessary revoke commands with the exception of:\n\n- Object Ownership\n- Warehouse Privileges\n\nFurthermore, if you are using the recommended role of `SECURITYADMIN`, `ALTER USER ...` commands will fail on users that are owned by `ACCOUNTADMIN`. In these circumstances, it is highly recommended to log into the Snowflake instance and update ownership of all users to belong to `USERADMIN` as per Snowflake recommended best practices.\n\nLastly, note that the default roles cannot have their role hierarchies modified. As such, any `GRANT ROLE <default role> TO ROLE <default role>;` will be excluded from the permission set generated by Permifrost.\n\nFor example:\n\n```yaml\n...\nroles:\n public:\n member_of:\n - useradmin\n securityadmin:\n member_of:\n - useradmin\n...\n```\nBoth of the above relationships will be skipped as this attempts to modify a default Snowflake permission structure which would generate an error on attempting to implement.\n\nPermifrost is heavily inspired by\n[pgbedrock](https://github.com/Squarespace/pgbedrock) which can be used for\nmanaging the permissions in a Postgres database.\n\n## spec_file\n\nThe YAML specification file is used to define in a declarative way the\ndatabases, roles, users and warehouses in a Snowflake account, together with the\npermissions for databases, schemas and tables for the same account.\n\nAll permissions are abbreviated as `read` or `write` permissions, with\nPermifrost generating the proper grants for each type of object. This includes\nshared databases which have simpler and more limited permissions than non-shared\ndatabases.\n\nAccording to the `read` vs. `write` permissions approach, you should be able to\ngrant granular access like `read` permissions for usage of database and schema\nand `write` permissions to insert data into a specific table within that\ndatabase and schema.\n\nPlease find below the links between Permifrost permissions and Snowflake grants.\n\n| Objects | Permifrost permissions | Snowflake grants |\n|-----------|------------------------|---------------------------------------------------------------------------------------------------------------------|\n| Databases | read | usage |\n| | write | monitor, create schema |\n| Schemas | read | usage |\n| | write | monitor, create table, create view, create stage, create file format, create sequence, create function, create pipe |\n| Table | read | select |\n| | write | insert, update, delete, truncate, references |\n\n\nTables and views are listed under `tables` and handled properly behind the\nscenes.\n\nIf `*` is provided as the parameter for tables the grant statement will use the\n`ALL <object_type>s in SCHEMA` syntax. It will also grant to future tables and\nviews. See Snowflake documentation for [`ON\nFUTURE`](https://docs.snowflake.net/manuals/sql-reference/sql/grant-privilege.html#optional-parameters)\n\nIf a schema name includes an asterisk (prefix or suffix), such as `snowplow_*` or `*_snowplow`, then all schemas\nthat match this pattern will be included in the grant statement _unless it is\nfor ownership_, in which case the asterisk is not supported. This can be coupled\nwith the asterisk for table grants to grant permissions on all tables in all\nschemas that match the given pattern. This is useful for date-partitioned\nschemas.\n\nAll entities must be explicitly referenced. For example, if a permission is\ngranted to a schema or table then the database must be explicitly referenced for\npermissioning as well. Additionally, role membership must be explicit in the\nconfig file. If a role does not have a `member_of` list, it will have all roles\nit currently has revoked.\n\nRoles can accept \"_\" as a role name either alone or nested under the `include`\nkey. There is optionally an `exclude` key that can be used if `include` is used.\n`\"_\"`will grant membership to all roles defined in the spec. Any roles defined\nin`exclude`will be removed from the list defined in`include`.\n\nObjects like warehouses and integrations that only have one permifrost permission type just\nneeds to be specified in the role (see below).\n\nObjects can have a `meta` dictionary which may contain information that is not relevant for Permifrost's\nexecution and are ignored by Permifrost itself.\n\nA specification file has the following structure:\n\n```bash\n# Databases\ndatabases:\n - db_name:\n shared: boolean\n - db_name:\n shared: boolean\n owner: role_name\n meta:\n some_key: some_value\n ...\n ... ... ...\n\n# Roles\nroles:\n - role_name:\n warehouses:\n - warehouse_name\n - warehouse_name\n ...\n\n member_of:\n - role_name\n - role_name\n ...\n\n # or\n\n member_of:\n include:\n - \"*\"\n exclude:\n - role_name\n\n privileges:\n databases:\n read:\n - database_name\n - database_name\n ...\n write:\n - database_name\n - database_name\n ...\n schemas:\n read:\n - database_name.*\n - database_name.schema_name\n - database_name.schema_partial_*\n - database_name.*_schema_partial\n\n ...\n write:\n - database_name.*\n - database_name.schema_name\n - database_name.schema_partial_*\n - database_name.*_schema_partial\n ...\n tables:\n read:\n - database_name.*.*\n - database_name.schema_name.*\n - database_name.schema_partial_*.*\n - database_name.*_schema_partial.*\n - database_name.schema_name.table_name\n ...\n write:\n - database_name.*.*\n - database_name.schema_name.*\n - database_name.schema_partial_*.*\n - database_name.*_schema_partial.*\n - database_name.schema_name.table_name\n ...\n\n owns:\n databases:\n - database_name\n ...\n schemas:\n - database_name.*\n - database_name.schema_name\n ...\n tables:\n - database_name.*.*\n - database_name.schema_name.*\n - database_name.schema_name.table_name\n ...\n\n meta:\n some_key: some_value\n ...\n\n - role_name:\n owner: role_name\n ... ... ...\n\n# Users\n# can_login is required the rest of the parameters are optional\n# None of the values are validated in Snowflake, hence default_warehouse, default_namespace and default_role\n# can contain invalid values\nusers:\n - user_name:\n can_login: boolean\n member_of:\n - role_name\n ...\n has_password: boolean\n display_name: string\n first_name: string\n middle_name: string\n last_name: string\n email: string\n comment: string\n default_warehouse: string\n default_namespace: string\n default_role: string\n meta:\n some_key: some_value\n ...\n - user_name:\n owner: role_name\n ... ... ...\n\n# Warehouses\n# Warehouse sizes are informative and not altered by Permifrost to align with the spec file\nwarehouses:\n - warehouse_name:\n size: x-small\n meta:\n some_key: some_value\n ...\n - warehouse_name:\n size: x-small\n owner: role_name\n ... ... ...\n\n# Integrations\n# Integration categories are informative and not altered by Permifrost to align with the spec file\nintegrations:\n - integration_name:\n category: storage\n meta:\n some_key: some_value\n ...\n - integration_name:\n category: security\n owner: role_name\n ... ... ...\n```\n\nFor a working example, you can check [the Snowflake specification\nfile](https://gitlab.com/gitlab-data/permifrost/blob/master/tests/permifrost/specs/snowflake_spec.yml)\nthat we are using for testing `permifrost permissions`.\n\nNote: The spec file must all be in lowercase.\n\n### Settings\n\nAll settings are declared here with their default values and are described\nbelow. These can be added to your spec.yaml file.\n\n```yaml\nrequire-owner: false\n```\n\n`require-owner`: Set to true to force having to set the `owner` property on all\nobjects defined.\n\n## --diff\n\nWhen this flag is set, a full diff with both new and already granted commands is\nreturned. Otherwise, only required commands for matching the definitions on the\nspec are returned.\n\n## --dry\n\nWhen this flag is set, the permission queries generated are not actually sent to\nthe server and run; They are just returned to the user for examining them and\nrunning them manually.\n\nWhen this flag is not set, the commands will be executed on Snowflake and their\nstatus will be returned and shown on the command line.\n\n## Connection Parameters\n\nThe following environmental variables must be available to connect to Snowflake:\n\n```bash\n$PERMISSION_BOT_USER\n$PERMISSION_BOT_ACCOUNT\n$PERMISSION_BOT_WAREHOUSE\n```\n\n### Username and Password\n\nTo connect using a username and password, also include the following:\n\n```bash\n$PERMISSION_BOT_PASSWORD\n$PERMISSION_BOT_DATABASE\n$PERMISSION_BOT_ROLE\n```\n\nCurrently, Permifrost assumes you are using the SECURITYADMIN role and will fail\nvalidation if you are not.\n\n### OAuth\n\nTo connect using an OAuth token, also include the following:\n\n```bash\n$PERMISSION_BOT_OAUTH_TOKEN\n```\n\n### External Browser SSO Auth\n\nTo connect using an external browser with SSO Auth, also include the following:\n\n```bash\n$PERMISSION_BOT_AUTHENTICATOR='externalbrowser'\n```\n\n### Key Pair Authentication\n\nRather than supplying a password or an oauth token, it's possible to connect via\nSnowflake's Key Pair authentication by setting the following:\n\n```bash\n$PERMISSION_BOT_KEY_PATH\n$PERMISSION_BOT_KEY_PASSPHRASE\n```\n\nSee [Snowflake-sqlalchemy](https://github.com/snowflakedb/snowflake-sqlalchemy#key-pair-authentication-support) for more info.\n\n## Contributing\n\nContributing to Permifrost is easy, and most commands to do so are available\nwithin the Makefile.\n\nThe easiest way to start developing is to run `make initial-setup` to install\nall the necessary packages to develop on the project. Next run `make\npermifrost` in a second terminal, this will open a shell in a docker container\nwith the local version of Permifrost installed.\n\nYou can now make changes to the files in your editor and it will be reflected in\nthe commands that you run from the docker shell.\n\nTo check code quality prior to committing changes, you can use `make local-lint`.\n\nSee the [Makefile](Makefile) for more details.\n\n**WARNINGS**\n\nDO NOT name git branches with forward slashes `/` as the current CI pipeline is\nunable to manage names like this. (i.e. `username/feature/feature-name` will\nbreak the CI pipeline so `username.feature.feature-name` should be used\ninstead)\n\nThis project has [pre-commit\nhooks](https://github.com/pre-commit/pre-commit-hooks) installed to maintain\nthe existing code quality. As such, we strongly recommend you use a terminal to\n**commit** and **push** code changes. Specifically, avoid using git\nintegrations on IDEs to make **commits** or **pushes**. **Adding** files\nthrough the IDE git integrations are okay, but do not **commit** through the\nIDE. Use the terminal to commit changes because it will show the output of each\nof the pre-commit checks to allow you to make changes as needed.\n\nFor committing work-in-progress changes use `git commit --no-verify -m \"WIP:\n<message>\"`.\n\nFor committing finalized changes, the below workflow will identify errors and allow for easier development:\n* Make your changes and `git add <file name(s)>`\n* `git commit` to identify/format errors in the changed files\n * Repeat the following steps until all checks pass\n * `git add <file name(s)>`\n * `git commit`\n* Add message at the prompt and save/exit the commit file\n* When you are ready to push changes to the remote host, run `git push origin <branch name>`. This will perform additional linting/formatting checks.\n * Repeat the following steps until all checks pass\n * `git push origin <branch name>`\n * `git add <file name(s)>`\n * `git commit`\n* Add message at the prompt and save/exit the commit file\n* `git push origin <branch name>` until all checks pass\n\n## Releasing\n\nSee the [issue template](https://gitlab.com/gitlab-data/permifrost/-/blob/master/.gitlab/issue_templates/Releasing%20update.md)\nfor guidance on how to release a new version of this project to PyPi\n",
"bugtrack_url": null,
"license": "MIT",
"summary": "Permifrost Permissions - Fork by Gemma Analytics",
"version": "0.1.3",
"project_urls": {
"Documentation": "https://github.com/Gemma-Analytics/permifrost",
"Homepage": "https://github.com/Gemma-Analytics/permifrost",
"Issues": "https://github.com/Gemma-Analytics/permifrost/issues",
"Repository": "https://github.com/Gemma-Analytics/permifrost"
},
"split_keywords": [
"snowflake",
" permissions",
" database",
" security"
],
"urls": [
{
"comment_text": null,
"digests": {
"blake2b_256": "f680c107ec94b2f94d7df010b206c440b7624306bad78048686289741d6f1fe4",
"md5": "a780e9bcaafdf0febf713185951bf584",
"sha256": "21bb079e95d331f111fa3d5206f6f3446f863c4016b3141e318e8f6cea484637"
},
"downloads": -1,
"filename": "gemma_permifrost-0.1.3-py3-none-any.whl",
"has_sig": false,
"md5_digest": "a780e9bcaafdf0febf713185951bf584",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.8",
"size": 40876,
"upload_time": "2025-08-15T16:05:01",
"upload_time_iso_8601": "2025-08-15T16:05:01.873123Z",
"url": "https://files.pythonhosted.org/packages/f6/80/c107ec94b2f94d7df010b206c440b7624306bad78048686289741d6f1fe4/gemma_permifrost-0.1.3-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": null,
"digests": {
"blake2b_256": "bf9f5e7309edb4541e9efbbb28be6696ba733f21f3098abc9f1f93ef2aafcd70",
"md5": "e1b349360178792bd30918035aab7a6e",
"sha256": "01dbd4850545b701b1a6f83b376edaa95dbd2adeb70d9247ddb64d9943c52e28"
},
"downloads": -1,
"filename": "gemma_permifrost-0.1.3.tar.gz",
"has_sig": false,
"md5_digest": "e1b349360178792bd30918035aab7a6e",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.8",
"size": 68421,
"upload_time": "2025-08-15T16:05:02",
"upload_time_iso_8601": "2025-08-15T16:05:02.878655Z",
"url": "https://files.pythonhosted.org/packages/bf/9f/5e7309edb4541e9efbbb28be6696ba733f21f3098abc9f1f93ef2aafcd70/gemma_permifrost-0.1.3.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2025-08-15 16:05:02",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "Gemma-Analytics",
"github_project": "permifrost",
"travis_ci": false,
"coveralls": true,
"github_actions": true,
"requirements": [
{
"name": "asn1crypto",
"specs": [
[
"==",
"1.4.0"
]
]
},
{
"name": "attrs",
"specs": [
[
"==",
"21.2.0"
]
]
},
{
"name": "azure-common",
"specs": [
[
"==",
"1.1.27"
]
]
},
{
"name": "azure-core",
"specs": [
[
"==",
"1.26.3"
]
]
},
{
"name": "azure-storage-blob",
"specs": [
[
"==",
"12.8.1"
]
]
},
{
"name": "backports.entry-points-selectable",
"specs": [
[
"==",
"1.1.0"
]
]
},
{
"name": "black",
"specs": [
[
"==",
"22.3.0"
]
]
},
{
"name": "boto3",
"specs": [
[
"==",
"1.18.32"
]
]
},
{
"name": "botocore",
"specs": [
[
"==",
"1.21.32"
]
]
},
{
"name": "bump2version",
"specs": [
[
"==",
"1.0.1"
]
]
},
{
"name": "bumpversion",
"specs": [
[
"==",
"0.6.0"
]
]
},
{
"name": "Cerberus",
"specs": [
[
"==",
"1.3.4"
]
]
},
{
"name": "certifi",
"specs": [
[
"==",
"2021.5.30"
]
]
},
{
"name": "cffi",
"specs": [
[
"==",
"1.14.6"
]
]
},
{
"name": "cfgv",
"specs": [
[
"==",
"3.3.1"
]
]
},
{
"name": "changelog-cli",
"specs": [
[
"==",
"0.7.1"
]
]
},
{
"name": "chardet",
"specs": [
[
"==",
"4.0.0"
]
]
},
{
"name": "charset-normalizer",
"specs": [
[
"==",
"2.0.4"
]
]
},
{
"name": "click",
"specs": [
[
"==",
"8.0.1"
]
]
},
{
"name": "click-default-group",
"specs": [
[
"==",
"1.2.2"
]
]
},
{
"name": "colorama",
"specs": [
[
"==",
"0.4.4"
]
]
},
{
"name": "coloredlogs",
"specs": [
[
"==",
"15.0.1"
]
]
},
{
"name": "coverage",
"specs": [
[
"==",
"5.5"
]
]
},
{
"name": "cryptography",
"specs": [
[
"==",
"3.4.8"
]
]
},
{
"name": "distlib",
"specs": [
[
"==",
"0.3.6"
]
]
},
{
"name": "filelock",
"specs": [
[
"==",
"3.9.0"
]
]
},
{
"name": "flake8",
"specs": [
[
"==",
"3.9.2"
]
]
},
{
"name": "greenlet",
"specs": [
[
"==",
"1.1.1"
]
]
},
{
"name": "humanfriendly",
"specs": [
[
"==",
"10.0"
]
]
},
{
"name": "identify",
"specs": [
[
"==",
"2.2.14"
]
]
},
{
"name": "idna",
"specs": [
[
"==",
"3.2"
]
]
},
{
"name": "iniconfig",
"specs": [
[
"==",
"1.1.1"
]
]
},
{
"name": "isodate",
"specs": [
[
"==",
"0.6.0"
]
]
},
{
"name": "isort",
"specs": [
[
"==",
"5.9.3"
]
]
},
{
"name": "jmespath",
"specs": [
[
"==",
"0.10.0"
]
]
},
{
"name": "mccabe",
"specs": [
[
"==",
"0.6.1"
]
]
},
{
"name": "msrest",
"specs": [
[
"==",
"0.6.21"
]
]
},
{
"name": "mypy",
"specs": [
[
"==",
"0.910"
]
]
},
{
"name": "mypy-extensions",
"specs": [
[
"==",
"0.4.3"
]
]
},
{
"name": "nodeenv",
"specs": [
[
"==",
"1.6.0"
]
]
},
{
"name": "oauthlib",
"specs": [
[
"==",
"3.1.1"
]
]
},
{
"name": "oscrypto",
"specs": [
[
"==",
"1.2.1"
]
]
},
{
"name": "packaging",
"specs": [
[
"==",
"21.0"
]
]
},
{
"name": "pathspec",
"specs": [
[
"==",
"0.9.0"
]
]
},
{
"name": "platformdirs",
"specs": [
[
"==",
"2.6.2"
]
]
},
{
"name": "pluggy",
"specs": [
[
"==",
"1.0.0"
]
]
},
{
"name": "pre-commit",
"specs": [
[
"==",
"2.15.0"
]
]
},
{
"name": "py",
"specs": [
[
"==",
"1.10.0"
]
]
},
{
"name": "pycodestyle",
"specs": [
[
"==",
"2.7.0"
]
]
},
{
"name": "pycparser",
"specs": [
[
"==",
"2.20"
]
]
},
{
"name": "pycryptodomex",
"specs": [
[
"==",
"3.10.1"
]
]
},
{
"name": "pyflakes",
"specs": [
[
"==",
"2.3.1"
]
]
},
{
"name": "PyJWT",
"specs": [
[
"==",
"2.1.0"
]
]
},
{
"name": "pyOpenSSL",
"specs": [
[
"==",
"20.0.1"
]
]
},
{
"name": "pyparsing",
"specs": [
[
"==",
"2.4.7"
]
]
},
{
"name": "pytest",
"specs": [
[
"==",
"6.2.5"
]
]
},
{
"name": "pytest-cov",
"specs": [
[
"==",
"2.12.1"
]
]
},
{
"name": "pytest-mock",
"specs": [
[
"==",
"3.6.1"
]
]
},
{
"name": "python-dateutil",
"specs": [
[
"==",
"2.8.2"
]
]
},
{
"name": "pytz",
"specs": [
[
"==",
"2021.1"
]
]
},
{
"name": "PyYAML",
"specs": [
[
"==",
"6.0.1"
]
]
},
{
"name": "regex",
"specs": [
[
"==",
"2021.8.28"
]
]
},
{
"name": "requests",
"specs": [
[
"==",
"2.26.0"
]
]
},
{
"name": "requests-oauthlib",
"specs": [
[
"==",
"1.3.0"
]
]
},
{
"name": "s3transfer",
"specs": [
[
"==",
"0.5.0"
]
]
},
{
"name": "six",
"specs": [
[
"==",
"1.16.0"
]
]
},
{
"name": "snowflake-connector-python",
"specs": [
[
"==",
"2.9.0"
]
]
},
{
"name": "snowflake-sqlalchemy",
"specs": [
[
"==",
"1.5.1"
]
]
},
{
"name": "SQLAlchemy",
"specs": [
[
"==",
"1.4.50"
]
]
},
{
"name": "toml",
"specs": [
[
"==",
"0.10.2"
]
]
},
{
"name": "tomli",
"specs": [
[
"==",
"1.2.1"
]
]
},
{
"name": "types-PyYAML",
"specs": [
[
"==",
"5.4.8"
]
]
},
{
"name": "types-click",
"specs": [
[
"==",
"7.1.7"
]
]
},
{
"name": "typing_extensions",
"specs": [
[
"==",
"4.5.0"
]
]
},
{
"name": "urllib3",
"specs": [
[
"==",
"1.26.6"
]
]
},
{
"name": "virtualenv",
"specs": [
[
"==",
"20.7.2"
]
]
}
],
"lcname": "gemma.permifrost"
}
