Palm CLI - the tool-belt for data teams

Overview

Palm CLI: The extensible CLI at your fingertips

Palm is a universal CLI developed to improve the life and work of data professionals.

Palm CLI documentation

Installing Palm

pip install palmcli

note for mac users: if you get this warning:

  WARNING: The script palm is installed in '/Users/yourname/Library/Python/3.8/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.

you will need to add '/Users/yourname/Library/Python/3.8/bin' to your path for palm to work.

you can do that with this command:

echo "\nexport PATH=$PATH:/Users/yourname/Library/Python/3.8/bin\n" >> ~/.zprofile

Requirements

  1. You will need Docker You can check to see if you already have it with docker --version

  2. You will need Python3 You can check to see if you already have it with python3 --version

Developing palm

If you have the repo on your computer This will install whatever version you have checked out at the moment.

cd path/to/this/repo &&
python3 -m pip uninstall palm || true # for new installs
python3 -m pip install . 

You can verify the install with

palm --help
Comments
  • Parameterized docker .env variables no longer auto-populate

    Parameterized docker .env variables no longer auto-populate

    Describe the bug Parameterized variables in docker file do not populate as env vars any longer. This is functionality that used to work.

    Your environment

    • palm version: 2.1.0
    • OS: Mac
    • Docker version: Docker version 20.10.10, build b485636, Docker Compose version v2.1.1
    • Other dependencies & versions:

    How to reproduce Build palm docker container with .env. Run the docker container and /bin/bash into it. Use the command printenv. Note that parameterized variables are not present.

    Expected behavior printenv shows parameterized variables in .env

    Actual behavior parameterized variables are not populated (e.g. SNOWFLAKE_USERNAME= )

    Screenshots If applicable, add screenshots to help explain your problem.

    Additional context Add any other context about the problem here.

    bug 
    opened by emekdahl-palmetto 8
  • [FEATURE] Global palm

    [FEATURE] Global palm

    Pull request checklist

    Before submitting your PR, please review the following checklist:

    • [x] Consider adding a unit test if your PR resolves an issue.
    • [x] All new and existing tests pass locally (palm test)
    • [x] Lint (palm lint) has passed locally and any fixes were made for failures
    • [x] Docs have been reviewed and added / updated if needed (for bug fixes / features)

    Breaking changes

    • [ ] Check if this pull request introduces a breaking change

    What does this implement/fix? Explain your changes.

    Being able to run palm outside of existing git projects unlocks a ton of new possibilities for palm.

    • Use discover_repository to allow us to raise and handle a custom exception in the case we are outside of a git repo
    • Change the implementation of branch detection so that we have proper control over when that check is executed
    • Update the implementation of palm_config.plugins to be a list with setters
    • Implement a global 'setup' plugin for OOTB global functionality, like new project scaffolding.

    Does this close any currently open issues?

    #14

    Any other comments?

    Globally configured palm plugins are available outside of repos, this allows users to create their own 'setup' plugins as needed. It's worth noting that we probably want to implement some mechanism for global plugins to exclude themselves from the global scope, as those may depend on being in the context of a git project.

    Where has this been tested?

    Operating System: MacOS

    opened by jakeberesford-palmetto 7
  • Support back to 3.6.9

    Support back to 3.6.9

    Pull request checklist

    Before submitting your PR, please review the following checklist:

    • [x] Consider adding a unit test if your PR resolves an issue.
    • [x] All new and existing tests pass locally (palm test)
    • [x] Lint (palm lint) has passed locally and any fixes were made for failures
    • [x] Docs have been reviewed and added / updated if needed (for bug fixes / features)

    Breaking changes

    • [ ] Check if this pull request introduces a breaking change

    What does this implement/fix? Explain your changes.

    Changes to the subprocess interface are not breaking going forward (3.6 => 3.7), but break going backwards from our primary 3.8 dev environment. This PR attacks 2 things:

    • fixes core compatibility back to python 3.6.9 (the stock python3 for Ubuntu 18.04, so a really common semi-recent version).
    • creates an abstracted run_on_the_metal() interface so we can protect downstream commands from the same issues

    Does this close any currently open issues?

    it makes a big dent in issue #20

    Any other comments?

    To keep this support clean in testing we should add a make option to build and test in virtualenvs for each minor release we want to cover in CI. it would just need to step through each one, run the tests etc.

    Where has this been tested?

    Locally with python3.6.9, python3.7.0, python3.9.9

    Operating System: Ubuntu 18.04

    opened by norton120 7
  • [FEATURE] Make command list easier to read

    [FEATURE] Make command list easier to read

    Pull request checklist

    Before submitting your PR, please review the following checklist:

    • [x] Consider adding a unit test if your PR resolves an issue.
    • [x] All new and existing tests pass locally (palm test)
    • [x] Lint (palm lint) has passed locally and any fixes were made for failures
    • [x] Docs have been reviewed and added / updated if needed (for bug fixes / features)

    Breaking changes

    • [ ] Check if this pull request introduces a breaking change

    What does this implement/fix? Explain your changes.

    When working with palm in some projects, you may have a lot of commands, coming from palm core, plugins, global plugins, and the project it's self. This list can be difficult to grok and find what you are looking for.

    By adding a custom format_commands function we can break that list up by plugin, making the command list easier to parse and find what you are looking for.

    Does this close any currently open issues?

    No. Just a thing I wanted to do.

    Any other comments?

    As yet, this is untested outside of a few tests on my local. I'd like to get tests around this and make sure it works well at the edges (e.g. subcommands in a regular command group).

    Where has this been tested?

    Operating System: MacOs

    opened by jakeberesford-palmetto 3
  • [WIP] Refactor to support running palm outside of an initialized git project

    [WIP] Refactor to support running palm outside of an initialized git project

    Pull request checklist

    Before submitting your PR, please review the following checklist:

    • [ ] Consider adding a unit test if your PR resolves an issue.
    • [ ] All new and existing tests pass locally (palm test)
    • [ ] Lint (palm lint) has passed locally and any fixes were made for failures
    • [ ] Docs have been reviewed and added / updated if needed (for bug fixes / features)

    Breaking changes

    • [ ] Check if this pull request introduces a breaking change

    What does this implement/fix? Explain your changes.

    • Use discover_repository to allow us to raise and handle a custom exception in the case we are outside of a git repo
    • Change the implementation of branch detection so that we have proper control over when that check is executed
    • Update the implementation of palm_config.plugins to be a list with setters
    • Implement a bare-bones 'setup' plugin as initial POC for the functionality

    Does this close any currently open issues?

    #12

    Any other comments?

    This is a WIP PR, still to be done:

    • [ ] implement new_machine
    • [ ] implement palm clone
    • [ ] document onboarding 'system' plugin commands
    • [ ] add tests around new functionality

    Where has this been tested?

    Operating System: Mac OS

    (RFC) Request For Comment no merge 
    opened by jakeberesford-palmetto 3
  • [FEATURE] Update commands to use `environment` over `ctx.obj`

    [FEATURE] Update commands to use `environment` over `ctx.obj`

    Pull request checklist

    Before submitting your PR, please review the following checklist:

    • [ ] Consider adding a unit test if your PR resolves an issue.
    • [x] All new and existing tests pass locally (palm test)
    • [X] Lint (palm lint) has passed locally and any fixes were made for failures
    • [X] Docs have been reviewed and added / updated if needed (for bug fixes / features)

    Breaking changes

    • [x] Check if this pull request introduces a breaking change

    What does this implement/fix? Explain your changes.

    Updated all instances of the @pass_context decorator to use @pass_object instead. Also updated any instances of ctx.obj to reference the context object environment for better code readability!

    Does this close any currently open issues?

    #45

    Any other comments?

    Where has this been tested?

    Operating System:

    Platform:

    Target Platform:

    opened by mariahjrogers 2
  • Plugin scaffold should protect against bad naming (

    Plugin scaffold should protect against bad naming ("palm-" prefix, special chars)

    Describe the bug

    This is really a feature, but feels like a bug when it's happening - so I'm calling it a bug first so others will be able to easily find the issue when it happens to them.

    TLDR new plugin names need to not be prefixed with palm- and be valid python class names.

    I wasn't clear on if my plugin should be named palm-git or git -even though the docs and help make it pretty clear. So I screwed that up and had to handhttps://github.com/palmetto/palm-cli/discussions-hack a lot of files to get it working. This isn't absolutely a bug but it is pretty very un-intuitive I think, and would be a solid fit to encourage contribution. Closely related, we create classnames from this name value - so we need to enforce that they are valid python. you can't have special chars in there etc etc.

    Your environment

    • palm version: 2.1.0
    • OS: Ubuntu 18.04
    • Docker version: Docker version 20.10.10, build b485636
    • Other dependencies & versions:

    How to reproduce use palm plugin new --name think about the name for 10 minutes, decide it should match the folder and call it palm-whatever spend a long time finding and deleting the palm prefixes from everything.

    Expected behavior remove palm- prefix from passed names, so people can make the mistake and we correct it for them. yell and abort when the formatted name is not valid python. OR always yell when the name is not valid python, and make it clear you don't need the palm prefix.

    Actual behavior Lots and lots of bad naming that needs to be manually corrected.

    bug good first issue 
    opened by norton120 2
  • move from

    move from "docker" to "container" to prepare for podman support

    Context Palm relies on containerization. Presently that has been 100% via Docker, but we'd like to expand the ecosystem to a fully OSS offering.

    Is your feature request related to a problem? Please describe. Docker is not OSS and there are limitations, and the learning curve for a thing like podman is not steep but does exist. We want to make the switch painless for our users, and we can start by abstracting "Docker" command aliases in palm to "container" commands. then under the hood we can run in the container engine of the user's choice.

    Describe the solution you'd like run_in_docker becomes run_in_container. Then under the hood we pipe the work to Docker, OR have the ability to use podman instead.

    Describe alternatives you've considered Stick with pure Docker support. Meh.

    Additional context This can start by abstraction and then balancing 100% of requests to a Docker mechanics class for now. That way we can roll podman as seperate work.

    Is there an existing feature request for this?

    • [x] I have searched the existing issues
    enhancement good first issue 
    opened by ethanknox-palmetto 2
  • Adding changelog for v2.1.0

    Adding changelog for v2.1.0

    Pull request checklist

    Before submitting your PR, please review the following checklist:

    • [ ] Consider adding a unit test if your PR resolves an issue.
    • [X] All new and existing tests pass locally (palm test)
    • [X] Lint (palm lint) has passed locally and any fixes were made for failures
    • [X] Docs have been reviewed and added / updated if needed (for bug fixes / features)

    Breaking changes

    • [ ] Check if this pull request introduces a breaking change

    What does this implement/fix? Explain your changes.

    We needed a changelog for 2.1.0!

    Does this close any currently open issues?

    Any other comments?

    opened by mariahjrogers 2
  • Logo Download and Branding Page

    Logo Download and Branding Page

    Before submitting your PR, please review the following checklist:

    • [ ] Consider adding a unit test if your PR resolves an issue. N/A
    • [x] All new and existing tests pass locally (palm test)
    • [x] Lint (palm lint) has passed locally and any fixes were made for failures
    • [x] Docs have been reviewed and added / updated if needed (for bug fixes / features)

    Breaking changes

    • [ ] Check if this pull request introduces a breaking change

    What does this implement/fix? Explain your changes.

    This adds the assets created by @davenix-palmetto and Margo Lanier (thanks again for the awesome work!) and some basic brand guidelines.

    Does this close any currently open issues?

    #10

    Where has this been tested?

    Operating System: MacOS

    Platform: Catalina

    Target Platform: All (readthedocs web)

    opened by norton120 2
  • pull subprocess into obj commands

    pull subprocess into obj commands

    Context Calling subprocess directly is messy. plus subprocess has breaking changes from python3.7 and up. And as a palm user, I really want a single interface for all palm commands in one place.

    Is your feature request related to a problem? Please describe. when I'm building out commands I not only need to know the palm interface, I need to know the subprocess one. most of the time I want a simple set of subprocess defaults, so let's provide them.

    Describe the solution you'd like ctx.obj has a run_on_the_metal method, with as close to the run_in_docker API as possible, and really opinionated defaults. If a user needs something more complex they can import subprocess themselves ;)

    Describe alternatives you've considered keep using subprocess

    Additional context To support older Pythons we will need to use conditional calls to Subprocess - so abstracting this is a really good idea.

    Is there an existing feature request for this?

    • [x] I have searched the existing issues
    enhancement 
    opened by ethanknox-palmetto 2
  • Update Install With Generic Drop-In Instructions

    Update Install With Generic Drop-In Instructions

    This makes the "add to path" command drop-and-go for mac/nix users 🚀

    • [x] Docs have been reviewed and added / updated if needed (for bug fixes / features)

    Breaking changes

    • [ ] Check if this pull request introduces a breaking change nope no breaking stuff

    What does this implement/fix? Explain your changes.

    This makes the "add to path" section of the docs a bit more agnostic - uses whatever python3 version is the current system default, and covers all 3 popular shells.

    Does this close any currently open issues?

    nope I don't think so

    Any other comments?

    This still doesn't help windoze folks, probably need to add that as well at some point to make the install docs super helpful.

    Where has this been tested?

    Operating System: Mac OS (M1) Ventura 13.1 (22C65)

    Platform: Bash shell

    Target Platform: Bash, Zsh, Fsh

    opened by norton120 0
  • Fix code scanning alert - Module is imported with 'import' and 'import from'

    Fix code scanning alert - Module is imported with 'import' and 'import from'

    Tracking issue for:

    • [ ] https://github.com/palmetto/palm-cli/security/code-scanning/7

    I think the code here can be simplified since we no longer support Python 3.6, this should remove the need for both import & import from

    opened by jakeberesford-palmetto 0
  • Create a

    Create a "command builder" that allows chaining w/ error handling inbetween

    Context Palm currently requires manual-ish command creation with strings which get passed to the container/host runner. We need a smart way for command chaining to occur so users aren't limited to a single command-line execution for their custom commands.

    Is your feature request related to a problem? Please describe. We currently have composite commands chain together with "&&", which requires every step in the command to complete successfully in order for the rest of the steps to run at all. This is a bug for palm-dbt (detailed in #17) because idempotency of dev/CI environments requires cleanup to execute regardless of model execution failure or success.

    Describe the solution you'd like Writing palm commands would be done through a palm library function for command building that provides chaining and the ability to handle errors. This would streamline development of new commands with repeated steps because you could simply chain together a set of existing commands in the desired execution order. Interface for a new command wouldn't appear as eg. dbt clean && dbt deps && dbt run && dbt test && dbt run-operation drop_branch_schemas. Instead, each command would be stored in a queue of some kind and executed one by one, with customization for whether a failure is raised to the process or handled, and customizable behavior depending on whether the preceding step succeeded or failed.

    Why? Because a one-size-fits-all approach bakes in a lot of our opinionated processes. Since I work most in dbt, I'll focus on that use-case. Palm-dbt has an extremely prescriptive approach to dbt runs, which is fine for now, but most certainly doesn't feel scalable, and does feel brittle. Every command in the plugin has repeated code inside it (dbt clean && dbt deps && dbt seed --full-refresh && ... run-operation drop_branch_schemas) and there are bugs in the way commands execute (like the example mentioned above).

    Chaining commands would allow us to specify how each piece of our completed command works independently. Then, you can chain them together safely with the confidence that it will just work. Users of plugins can use the building blocks of all the pieces that exist, with the ability to chain them together in different orders, with different default behavior, without reinventing the whole wheel.

    Eg. new functionality for palm cycle inside a dbt project, utilizing palm-dbt:

    def dbt_run(..., raise_error=False):
        try:
            result = run_in_docker('dbt run')
        except model_build_failures:
            if raise_error == True:
                raise model_build_failures
        return result
    ...
    # palm cycle
    def cli(count=2):
        cmd = palm.command_builder()
        cmd.add(dbt_clean)
        cmd.add(dbt_deps)
        while count > 0:
            cmd.add(dbt_run)
            cmd.add(dbt_test, depends_on_previous=True)
            count -= 1
        cmd.add(dbt_cleanup, raise_error=True)
        cmd.execute() # execution of all commands in the builder in above order
    

    And the interface for a user running the command:

    $ palm cycle 1
    Executing `dbt clean`...
    Clean as a whistle!
    Executing `dbt deps`...
    All dependencies installed!
    Executing `dbt run`...
    Oops, some models failed to build. Skipping test...
    `dbt test` skipped due to model build failures
    Executing `dbt run-operation drop_branch_schemas`...
    Schema `test.mrogers_test_new_feature_01993049` cleaned up.
    

    Then, a user of palm-dbt decides they want dbt test to run even if dbt run has model failures. They override palm cycle with their own command, changing only one line from our version:

    def cli(count=2):
        cmd = palm.command_builder()
        cmd.add(dbt_clean)
        cmd.add(dbt_deps)
        while count > 0:
            cmd.add(dbt_run)
            cmd.add(dbt_test)
            count -= 1
        cmd.add(dbt_cleanup, raise_error=True)
        cmd.execute()
    
    $ palm cycle
    Executing `dbt clean`...
    Clean as a whistle!
    Executing `dbt deps`...
    All dependencies installed!
    Executing `dbt run`...
    Oops, some models failed to build.
    Executing `dbt test`...
    Oops, some tests failed!
    Executing `dbt run-operation drop_branch_schemas`...
    Schema `test.mmoulds_test_another_feature_01856927` cleaned up.
    

    Describe alternatives you've considered Option: Keep things as they are. Pros: This is simple for users writing new commands because they only have to think about how to execute code exactly as they would do it in the terminal. Single step commands are straightforward because they only require one execution. Advanced users can make use of our initial progress in this direction with our dbt_palm_utils functions, or the way palm cycle is implemented with a make_cmd() function. Cons: Usefulness of these existing functions is limited because they are currently only available in palm-dbt; commands aren't reusable with library functions, so there's a lot of repeated code. Commands are built as strings concatenated together before being passed to the host/container runners, which is very brittle and prone to introducing bugs, since the interpreter can't identify bugs in the commands.

    Option: Break all existing commands apart at the "&&" and run them in sequence with separate run_in_docker calls. Pros: Better for error handling. Cons: No clean way for modular, reusable commands to exist because each call to the runner will still execute independently and commands still won't have a library function interface.

    Additional context This feels awkwardly like trying to implement workflow orchestration. If using an existing orchestrator inside palm were an option, I would totally go with doing that as long as it is as platform agnostic as palm currently is. Otherwise, I think we could still do this simply enough that would provide a ton of value.

    Is there an existing feature request for this?

    • [X] I have searched the existing issues
    enhancement 
    opened by mariahjrogers 0
  • Bash and / or Zsh completion

    Bash and / or Zsh completion

    Context What are you trying to do and how would you want to do it differently? Is it something you currently cannot do?

    I want to have the same bash / zsh completion when I shell in using docker that I would on my local

    Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

    I want to run commands as fast as I can on my local dbt project outside of docker and have access to the history

    Describe the solution you'd like A clear and concise description of what you want to happen.

    Something like this in the docker file? This is just an inspiration not an implementation.

    RUN echo 'source /usr/share/bash-completion/bash_completion' >> /etc/bash.bashrc

    Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

    Additional context Add any other context or screenshots about the feature request here.

    Is there an existing feature request for this?

    • [x] I have searched the existing issues
    enhancement 
    opened by emekdahl-palmetto 1
  • Use @pass_obj instead of @pass_ctx

    Use @pass_obj instead of @pass_ctx

    Context We use the click context heavily in palm commands since this is how we access the Environment for core functions like run_in_docker. The syntax is a little awkward as we have to access the Enviornment via ctx.obj, which is a click convention. We can improve the readability of our code by changing the implementation to use @pass_obj instead, and naming the first arg environment - this makes reasoning about how commands work much more clear for users who are unfamiliar with click.

    Is your feature request related to a problem? Please describe. ctx.obj.run_in_docker is a little mysterious enviornment.run_in_docker is more clear.

    Describe the solution you'd like

    • Update all core commands to use pass_obj
    • rename arg ctx -> `environment
    • Update uses of ctx.obj -> environment

    Describe alternatives you've considered

    • Click also has make_pass_decorator which could allow us to @pass_environment, but since the Environment constructor has required arguments, this will not work
    • Once we implement palm.decorators, we will likely add our own decorator for @pass_environment which would work in much the same way as @pass_obj, this issue is one step in that direction

    Additional context I have tested this and confirmed it works as described.

    Is there an existing feature request for this?

    • [x] I have searched the existing issues
    enhancement good first issue 
    opened by jakeberesford-palmetto 0
  • Autodocs

    Autodocs

    Context Our rtd documentation does not have code docs. Since we use Google Python heredocs, we can support autodocumentation generation.

    Is your feature request related to a problem? Please describe. Right now the only way to see the interface to palm is to read the code directly :(

    Describe the solution you'd like Autodocs are built automatically from the code heredocs in our rtd documentation. Probably use Napoleon for compiling, and sensible settings (don't expose private methods, constants etc etc).

    Describe alternatives you've considered Manually building code docs.. why?

    Additional context We may also want a simple "cheat sheet" that is manually maintained and parsed from these. But real autodocs are huge.

    Is there an existing feature request for this?

    • [x] I have searched the existing issues
    documentation enhancement good first issue 
    opened by ethanknox-palmetto 1
Releases(2.5.1)
  • 2.5.1(Nov 23, 2022)

  • 2.5.0(Nov 22, 2022)

    Added

    • Global palm allows palm to run outside of initialized git projects. This feature opens up many new possibilities for automation with palm, including project scaffolding with cookiecutter, machine setup, and global plugins that can do just about anything!
    • Project scaffolding with cookiecutter. Palm now includes cookiecutter for scaffolding new projects. Why would you use palm for this, instead of using cookiecutter directly? Because with palm, you're able to configure a set of default cookiecutter templates, which helps keep projects consistent. Every developer, on every team, should use the same set of templates!
    • Plugin Configs enable plugins to define a configuration object which is persisted in the .palm/config.yml. Configurations are defined by the plugin and made available to each command via the palm environment. The next release of palm-dbt will include a working example of Plugin Configuration!
    • Pre-commit Added pre-commit hooks to palm to improve contributor experience.
    • Continuous deployment via github actions workflow.
    • Additional Dependencies palm-cli now depends on cookiecutter >= 2.0 for project scaffolding via palm new and pydantic >= 1.9 for Plugin Configs.

    Changed

    • linting & cleanup as a result of adding more tools in out pre-commit hooks, we also cleaned up some poorly formatted files in the project!.
    • Use pass_obj all core commands now use @click.pass_obj to provide the palm environment to the command, rather than the more convoluted @click.pass_context()
    Source code(tar.gz)
    Source code(zip)
    palm--2.5.0-py3-none-any.whl(35.55 KB)
    palm--2.5.0.tar.gz(20.38 KB)
  • v2.4.1(Jun 8, 2022)

    Improvements

    • Improved layout for palm --help: Palm help now outputs the command list in groups based on the plugin the command originates from! This is particularly helpful when working in a project that defines uses plugins, defines it's own commands, and you have global plugins installed!

    Bug fixes

    • Fixed a path issue for windows users when using code_gen or palm init
    • Fixes a potential security vulnerability when upgrading plugins via palm plugin update
    • Fixes a number of other small issues detected by CodeQL static anlysis
    Source code(tar.gz)
    Source code(zip)
  • v2.4.0(May 10, 2022)

    Features:

    • Run docker commands without /bin/bash - Added optional arguments to environment.run_in_docker allows developers to execute commands in their docker containers without prepending them with /bin/bash -c. This is useful & necessary for images with a specific entrypoint

    Improvements:

    • Added documentation New documentation for:
      • Global palm configuration
      • Shell autocomplete
      • Upgrading palm
    Source code(tar.gz)
    Source code(zip)
  • v2.3.0(Mar 28, 2022)

    Features:

    • Override command The new palm override command makes it easy to change the functionality of core or plugin commands in your project.
    • git repo added to palm config Developers can now access the pygit2 Repository via the context.obj.palm.config - this can be helpful when implementing commands that use git or need data from the repo.

    Improvements

    • Startup speed changed the implementation of checking docker-compose is installed, this fixes intermittent slowdowns on startup
    • Dependency upgrades: Click updated to v8.1 and up, Black updated to v22.3.0
    Source code(tar.gz)
    Source code(zip)
  • v2.2.0(Feb 24, 2022)

    Python Version Support"

    • Dropped support for python3.6 Python 3.6 is end of life and supporting it started to cause issues with dependent packages. We are dropping support for python 3.6 in palm v2.2.0

    Features:

    • Global config & Global plugins Palm now supports installing plugins globally! After updating to palm 2.2.0, the first time you run palm ... a new global config will be created at ~/.palm/config.yaml, you can add plugins to this config to make them available to all of your repositories! This feature was developed to support a Palmetto internal palm-workflow plugin, which is used to manage our dev workflow in Trello.

    Bug Fixes:

    • pygit2 version pin adjusted: The upper version pin on pygit2 was removed to resolve an error installing palm on newer versions of MacOS. Note that libgit2 is still required, per the requirements of pygit2. A future version will introduce checking for libgit2 and more friendly error messaging.
    • Upgraded jinja: We were previously using an unsupported version of Jinja which was using a deprecated method in markupsafe, markupsafe removed that method which caused an error when installing palm. We upgraded to the latest version of jinja to resolve this issue and get the latest jinja features.
    Source code(tar.gz)
    Source code(zip)
  • v2.1.1(Feb 7, 2022)

    Bug fixes

    • Resolve a template issue when running palm plugin new

    Improvements

    • Command templates now use click's @pass_obj decorator and pass the environment argument, this is a cleaner API for interacting with the Palm.Environment class
    • CI now runs against multiple python versions
    • Black version is pinned for consistency between local & CI runs
    Source code(tar.gz)
    Source code(zip)
  • v2.1.0(Dec 2, 2021)

    2.1.0

    12/01/2021

    Our first minor release on v2 includes containerization, support for older Python versions, and added logo and brand assets!

    Features:

    • Containerize: NEW command added for containerization of Python projects with palm containerize
    • Shell: NEW command to shell into the project container and execute arbitrary commands
    • Plugin generator: NEW command to generate the boilerplate code for writing a new plugin
    • Excluded commands: Added the ability to exclude/disable palm commands from a project's config
    • run_on_host: Added a new function, ctx.obj.run_on_host, to assist with developing new commands to run on your local machine, standardizing the interface around Python's subprocess with platform and version agnostic support (well, version agnostic >= 3.6.9).
    • Logo/Branding: We have a logo!! It is 90's retro and it is cool. Also added branding guidelines

    Improvements:

    • Command availability: Added lint and test commands to the palm core plugin
    • Workflow: New Github Actions workflow to lint contributions to the project on new Pull Request
    • Backwards compatibility: Added backwards compatibility support for older Python versions through v3.6.9
    • Documentation: Added new docs and examples of palm use cases and impact
    Source code(tar.gz)
    Source code(zip)
  • v2.0.1(Nov 10, 2021)

  • v2.0.0(Nov 10, 2021)

    This major version marks our first open-source release, and thus the first version with a changelog entry!

    Features

    • Plugins commands for Palm CLI are now largely driven by a plugin architecture. All commands in Palm are made available by one of several plugins. The core plugin and repo plugin are part of the Palm-cli repository and provide global commands as well as commands defined within the project's .palm directory. Additional plugins such as palm-dbt can be installed on the user's machine and configured for use on a per-project basis. See the plugin section of the docs for more information
    • Palm config Palm now reads a config.yaml file from the current project's .palm directory. This configuration enables the plugin architecture and allows us more flexibility around protecting specific branches and determining the docker image name.
    • Dependency detection Since docker is a core requirement for using Palm, we added checks to ensure docker and docker-compose are installed and running.
    • Documentation Palm documentation has been enhanced with readthedocs, and now includes standard documentation for OSS projects, e.g. Contribution guide, code of conduct, and this changelog!
    • Test suite Palm now has a good baseline of test coverage!

    Improvements

    • General cleanup - Code was reformatted for PEP8 compliance
    • Naming - Renamed run_in_shell to run_in_docker, run_in_shell will be deprecated in a future version.
    Source code(tar.gz)
    Source code(zip)
Owner
Palmetto
Palmetto
Container images for portable development environments

Docker Dev Spin up a container to develop from anywhere! To run, just: docker run -ti aghost7/nodejs-dev:boron tmux new Alternatively, if on Linux: p

Jonathan Boudreau 163 Dec 22, 2022
Play Wordle Bot - Wordle Bot written in python

Wordle Bot A Bot written in python with a CL Interface to guess adn solve Wordle

Prashant 1 Feb 25, 2022
The WalletsNet CLI helps you connect to WalletsNet

WalletsNet CLI The WalletsNet CLI helps you connect to WalletsNet. With the CLI, you can: Trigger webhook events or resend events for easy testing Tai

WalletsClub 8 Dec 22, 2021
Use case: quick JSON processing/restructuring with jq without terminal

alfred-jq Alfred workflow to conveniently process JQ on clipboard based on a jq query Also available at: packal/jq Use case: quick JSON processing/res

T on Meta Mode 5 Sep 30, 2022
Microsoft Azure CLI - Azure Command-Line Interface

A great cloud needs great tools; we're excited to introduce Azure CLI, our next generation multi-platform command line experience for Azure.

Microsoft Azure 3.4k Dec 30, 2022
Python Processing Tool for Vasp Ipnut/Output

PivotPy A Python Processing Tool for Vasp Input/Output. A CLI is available in Powershell, see Vasp2Visual. stylea{text-decoration: none !important;c

Abdul Saboor 5 Aug 16, 2022
Unpacks things.

$ unp_ unp is a command line tool that can unpack archives easily. It mainly acts as a wrapper around other shell tools that you can find on v

Armin Ronacher 405 Jan 03, 2023
CLI/library to control FNIRSI DC Power Supply (DC-6006L, etc)

dc6006l - CLI/library to control FNIRSI DC Power Supply (DC-6006L, etc) What is this? FNIRSI DC6006L is a programmable DC power supply that is quite c

Taisuke Yamada 7 Sep 25, 2022
A minimalist Vim plugin manager.

A minimalist Vim plugin manager. Pros. Easy to set up: Single file. No boilerplate code required. Easy to use: Concise, intuitive syntax Super-fast pa

Junegunn Choi 30.2k Jan 08, 2023
CLI to show end-of-life dates for tools and technologies.

Python 3.9+ interface to endoflife.date to show end-of-life dates for tools and technologies.

Hugo van Kemenade 32 Jan 06, 2023
A web shell client written in python.

Webshell client A webshell client written in python. Only works well for linux for the time being. Why? Because there are too many heavy webshells. So

tchar 1 Dec 07, 2021
Simple and convenient console ToDo list app

How do you handle remembering all that loads of plans you are going to realize everyday? Producing tons of paper notes, plastered all over the house?

3 Aug 03, 2022
xonsh is a Python-powered, cross-platform, Unix-gazing shell

xonsh is a Python-powered, cross-platform, Unix-gazing shell language and command prompt.

xonsh 6.7k Dec 31, 2022
Gamma ion pump QPC ethernet Python library & CLI utility

Unofficial Gamma ion pump ethernet control CLI utility and library This is a mini Python 3 library and utility that exposes some of the functions of t

2 Jul 18, 2022
Squirrel - A cli program to track writing progress

Squirrel Very much a WIP project squirrel is a command line program that tracks you writing progress and gives you useful information and cute and pic

3 Mar 23, 2022
A Hikari command handler for people who love ducks.

A Hikari command handler for people who love ducks.

Jeremiah 2 Oct 09, 2022
Declarative CLIs with argparse and dataclasses

argparse_dataclass Declarative CLIs with argparse and dataclasses. Features Features marked with a ✓ are currently implemented; features marked with a

Mike DePalatis 29 Dec 06, 2022
A terminal application for managing images and artifacts in Azure Container Registry.

acr-browser acr-browser is a terminal-based user interface for managing container images and artifacts in Azure Container Registry. 🚀 This project ow

Sam Dobson 5 Jul 30, 2022
Kubernetes shell: An integrated shell for working with the Kubernetes

kube-shell Kube-shell: An integrated shell for working with the Kubernetes CLI Under the hood kube-shell still calls kubectl. Kube-shell aims to provi

CloudNative Labs 2.2k Jan 08, 2023
A minimal todo list for your terminal.

todo A minimal todo list for your terminal. Installation Run the following command. pip install git+https://github.com/piero-vic/todo.git Usage todo

Piero Lescano 7 Aug 08, 2022