If you’re a Python developer who uses Poetry to manage your project dependencies and Pyenv to manage multiple Python versions, you may want to change the Python version that Poetry is using. This can be a bit confusing at first, but with the right steps, it can be done quickly and easily. In this post, we’ll show you how to change the Python version that Poetry uses if you’re using Pyenv.
Prerequisites:
Before we begin, make sure you have the following prerequisites:
Poetry installed on your machine
Pyenv installed on your machine
At least two Python versions installed with Pyenv
Steps
Open your terminal and navigate to the directory of your project.
Check which Python version Poetry is currently using by running the following command:
$ poetry run python --version
This will show you the current Python version that Poetry is using.
Check which Python versions are installed with Pyenv by running the following command:
$ pyenv versions
This will show you a list of all the Python versions installed with Pyenv. To sync the version used by Poetry with the one by Pyenv, we can enable the following option.
Choose the Python version you want to use with Poetry and set it as the global version by running the following command:
$ pyenv global <PYTHON_VERSION>
Replace with the version of Python you want to use.
Verify that the global Python version has been changed by running the following command:
$ python --version
This will show you the current Python version that your system is using.
Verify that Poetry is now using the correct Python version by running the following command:
$ poetry run python --version
This should show you the version of Python you set in step 4.
If you need to switch back to a different Python version, repeat steps 4-6 with the version you want to switch to.
Conclusion:
In this post, we’ve shown you how to change the Python version that Poetry is using if you’re using Pyenv to manage multiple Python versions. By following these steps, you can easily switch between different Python versions and ensure that your project is using the correct version of Python.
1Password Shell Plugin Update Adds Support for TreasureData Toolbelt
1Password will release an update to its shell plugin that adds support for the TreasureData Toolbelt. The TreasureData Toolbelt is a command-line interface (CLI) tool that allows users to interact with the TreasureData platform.
I have submitted a pull request to support this and it’s merged into master branch.
You can use this plugin with 1Password CLI 2.16.0 or later.
To use the 1Password plugin with the TreasureData Toolbelt, you must first set up the toolbelt in your environment. This involves creating a TreasureData account, obtaining an API key, and installing the toolbelt. Once the toolbelt is set up, you can build and test the TreasureData plugin locally using the instructions provided in the documentation.
$ make treasuredata/validate
$ make treasuredata/build
To import your TreasureData credentials into 1Password, you must first initialize the plugin and test the importer using the config file located at ~/.td/td.conf. The plugin will create an entry in 1Password that includes the user and api key fields. Once the credentials are saved in 1Password, you can use them to authenticate with TreasureData when running commands.
To ensure that the credentials are being properly stored and accessed at runtime, the provisioner included in the plugin will inject the TD_API_KEY environment variable when running TreasureData commands. This ensures that the toolbelt can refer to the necessary credential at runtime. To test the provisioner, run a td command and ensure that the credentials are being properly retrieved. This injection is opted out when we use the option such as -c or -k which precedes every other configuration.
Overall, the 1Password shell plugin update adds a new level of convenience and security to interacting with the TreasureData platform. With the plugin, users can easily store and access their credentials in 1Password, eliminating the need to store them in plain text or remember them.
When you try to clone the repository with HTTPS protocol, you must see the following message at least once.
$ git clone https://github.com/foo/bar.git
Cloning into 'bar'...
Username for 'https://github.com': xxx
It’s easy to resolve this issue. We just put the username and the token issued in the personal access token page in the GitHub settings.
But what if you do not have any option to set the token by yourself? In a situation like using Homebrew to clone the repository with HTTPS protocol?
We can cache the credentials of GitHub in Git so that we can use these credentials even if we do not have any way to control the external script execution.
Run gh auth login and select HTTPS as your preferred procotol.
Now, you should be able to clone the repository with HTTPS protocol without specifying the username and personal access token explicitly. Git automatically takes care of that.
Poetry allows us to manage the Python packages in a sandboxed environment neatly. My experience using Poetry was excellent, and I have replaced my Python way with Poetry from Pipenv.
But I sometimes found Poetry failed to resolve the dependencies because of the unsupported Python version used by the environment. For example, it shows the following error message.
The currently activated Python version 3.7.14 is not supported by the project (^3.9).
Trying to find and use a compatible version.
Some packages I used were not compatible with Python 3.7 in this case. But I was confused because my local PATH leads to Python 3.9 thanks to Pyenv. So how can I specify the project-specific python version?
The answer was simple. It needs to be more to specify the PATH by pyenv. We also need to set the python version by init or env use subcommands.
$ poetry init --python 3.9
OR
$ poetry env use 3.9
It tells the Poetry environment to use this Python version explicitly. With these settings, we can install all dependencies without any problem.
I used the GPG key to sign my Git commit. This is because it’s beneficial to show my commit’s identity and authenticity publicly. The signed commit, appropriately associated with the email registered in GitHub, will get the verified mark in the UI.
But you can use the SSH key to sign the commit alternatively. It’s a better and easier way because most GitHub users already should register their SSH keys to push the code to GitHub. Therefore, we do not need to prepare another key only for signing the Git commit.
First, you tell Git to use the SSH key to sign commits and tags as a default way.
At last, please make sure to register this key as a Signing keys found in the settings. I thought registering the key in Authentication keys would be enough, but it did not work. Check the Signing keys section in your GitHub account’s SSH and GPG keys setting.
That’s it. You will see your commit is appropriately verified when you submit some patches into GitHub next time.
