Forem: Pedro Caldeira

Exploring Python Environments with PyEnv

Pedro Caldeira — Mon, 11 Dec 2023 01:14:35 +0000

Introduction

Python developers often encounter scenarios where they must manage multiple Python versions and virtual environments. This is where pyenv comes to the rescue. pyenv is a simple yet powerful tool that allows you to easily install, manage, and switch between different Python versions on your system.

In this blog post, we'll explore the fundamental operations of pyenv, including installation, creating and managing environments, and utilizing the virtualenv plugin for more advanced use cases.

Installing `pyenv`

Before diving into pyenv, let's install it on your machine. The process is straightforward:

curl https://pyenv.run | bash

# Add the following to your shell profile (.bashrc, .zshrc, etc.)
if command -v pyenv 1>/dev/null 2>&1; then
  eval "$(pyenv init --path)"
  eval "$(pyenv virtualenv-init -)"
fi

Basic Operations

Listing Available Python Versions

To see which Python versions are available for installation, use:

pyenv install --list

Installing a Python Version

Install a specific Python version with:

pyenv install 3.8.12

Setting the Global Python Version

Set a global Python version for your system:

pyenv global 3.8.12

Creating a Virtual Environment

Create a virtual environment for your project:

pyenv virtualenv 3.8.12 myenv

Activating and Deactivating Environments

Activate an environment:

pyenv activate myenv

Deactivate the current environment:

pyenv deactivate

Advanced Usage with the Virtualenv Plugin

pyenv can be extended with plugins. One such helpful plugin is pyenv-virtualenv. Install it via:

git clone https://github.com/pyenv/pyenv-virtualenv.git $(pyenv root)/plugins/pyenv-virtualenv

Creating Virtual Environments with the Plugin

pyenv virtualenv 3.8.12 myenv

Activating and Deactivating Environments with the Plugin

pyenv activate myenv

pyenv deactivate

Listing Virtual Environments

pyenv virtualenvs

Understanding `pyenv local`, `pyenv global`, and `pyenv shell`

When working with pyenv, you have three main commands for managing Python versions on different levels: pyenv local, pyenv global, and pyenv shell.

1. `pyenv local`

The pyenv local command allows you to set a local Python version for a specific project or directory. This is particularly useful when different projects require different Python versions. When you run pyenv local, a file named .python-version is created inside the project directory, specifying the desired Python version.

Usage:

cd your_project_directory
pyenv local 3.8.12

This creates a .python-version file in your project directory containing the version information.

Now, whenever you navigate this project directory or its subdirectories, pyenv will automatically switch to the specified Python version. This local configuration is project-specific, making it convenient to manage dependencies per-project basis.

2. `pyenv global`

On the other hand, pyenv global sets the global Python version for your entire system. This default Python version will be used without a local or shell-specific configuration.

Usage:

pyenv global 3.9.5

This command sets the global Python version to 3.9.5. It's handy when you want to define a default Python version for your entire development environment.

3. `pyenv shell`

The pyenv shell command sets a Python version for the current shell session. Unlike pyenv local, it does not create a configuration file. Instead, it affects only the current shell session.

Usage:

pyenv shell 3.7.9

This command sets the Python version for the current shell session to 3.7.9. It's useful for temporary changes within a terminal window.

Focus on `pyenv local`

The real strength of pyenv local lies in its ability to create a project-specific configuration. By generating a .python-version file within your project directory, pyenv ensures that the correct Python version is automatically activated every time you enter that directory.

This feature is especially valuable in collaborative projects or when working on multiple projects with different Python requirements. It promotes consistency and avoids conflicts by encapsulating the Python version within the project's directory.

Next time you embark on a new project, consider using pyenv local to manage Python versions effortlessly on a per-project basis.

Conclusion

In conclusion, pyenv stands out as a straightforward and efficient tool for managing Python versions and virtual environments, providing simplicity for Python-centric projects with commands like pyenv local, pyenv global, and pyenv shell. Notably, the elegance of pyenv local lies in its ability to create project-specific configurations, facilitating seamless transitions between diverse project environments. However, as the complexities of projects grow, the environment management landscape expands to encompass broader needs.

Resources

Transitioning from Docker to Podman: Navigating Challenges and Practical Solutions

Pedro Caldeira — Mon, 04 Dec 2023 03:43:39 +0000

Introduction

Containers in software development encapsulate applications with dependencies, offering portability and consistency across computing environments. Docker and Podman, prominent containerization platforms, provide distinct features.

Docker Overview

Widely adopted, Docker simplifies application creation, deployment, and management with a client-server architecture, CLI, and graphical interface. Seamless image sharing contributes to its popularity among developers and operations teams.

Podman Overview

Podman, a popular alternative tool, distinguishes itself with a daemonless architecture. Operating without a central background process, it offers a CLI similar to Docker, prioritizing security and simplicity.

Both Docker and Podman adhere to OCI standards, revolutionizing software development practices.

Context

Docker's subscription-based pricing for enterprise services contrasts with Podman's open-source model, making it cost-effective for organizations. This distinction is crucial for smaller businesses seeking functionality without hefty costs. Podman's lack of a daemon adds to its appeal, providing a simpler and potentially more resource-efficient alternative for users favoring a daemonless approach to container management.

Exploring Podman

Aliasing for Seamless Transition

My initial step involved creating an alias from "docker" to "podman" and incorporating it into my .bashrc. This way, I can continue using the familiar "docker" command while the underlying implementation is Podman.

alias docker=podman

$ docker --version
podman version 4.4.1

This aliasing approach is particularly handy when dealing with legacy scripts already set up for Docker, eliminating the need for immediate replacements.

Daemonless Operation

Podman's standout feature, its daemonless architecture, may pose challenges for libraries and applications previously integrated with Docker and its daemon. In a Python script example utilizing the "docker" module, attempting to initialize it resulted in the following error:

Unable to initialize Docker client. Check that the Docker daemon is running and try again. Exception received from docker.from_env() command: Error while fetching server API version: ('Connection aborted.', PermissionError(13, 'Permission denied'))

To resolve this issue:

Identify your Podman socket:

   podman info --format '{{.Host.RemoteSocket.Path}}'

Set DOCKER_HOST as your Podman socket obtained in step 1.

   $ export DOCKER_HOST=unix://<your_podman_socket_location>

Optional: Consider adding this variable to your .bashrc for convenience.

Addressing Permission Denied Issues

Podman usage may encounter various issues, including permission-denied errors. For an exhaustive list of potential problems, refer to this resource.

In my experience, a Docker image that functioned well with Docker faced permission-denied errors with Podman. Even running with sudo did not resolve the issue.

I discovered that Podman, by default, restricts Linux capabilities in its containers, leading to permission errors. To overcome this:

Add --cap-add all to your script:

podman run --cap-add all <your_image>

While this isn't a permanent solution, it served my one-time use case. For a more robust approach, identify the necessary capabilities and replace the "all" argument accordingly. However, this provided a quick and effective resolution for a single-use scenario.

Conclusion

In summary, Podman presents itself as a more resourceful option than Docker, with notable strengths in security and flexibility. However, potential challenges and disruptions in transitioning should be considered, especially for projects already established on Docker. Whether the move to Podman is worth depends on your project's specific needs and requirements. If the enhanced features and resource efficiency align with your objectives, navigating the transition complexities may prove beneficial; otherwise, sticking with Docker might be the more pragmatic choice for your current setup.

Diving into the Deep: My Inaugural PyTorch Contribution Adventure!

Pedro Caldeira — Fri, 24 Nov 2023 02:20:51 +0000

Context

In my quest to showcase my coding prowess in both Python and CUDA, and to prove my adeptness at seamlessly navigating diverse codebases, I sought out an opportunity for contribution. The natural choice was PyTorch, a prominent open-source machine learning library. What better way to demonstrate my versatility than by engaging with a project at the forefront of the deep learning landscape? PyTorch presented the perfect challenge, requiring a blend of Python expertise and an understanding of CUDA for efficient GPU acceleration. By diving into this vibrant community, I aimed to contribute substantively and underscore my ability to transition seamlessly between programming languages and tackle intricate, large-scale codebases. It's a journey of skill validation and a testament to my commitment to mastering the intricacies of cutting-edge technologies. 🚀🐍🔥

Finding an issue

My initial foray into contributing to PyTorch involved the crucial step of identifying a suitable issue to tackle. Navigating through the repository, I honed in on issues tagged with "good first issue" labels, recognizing them as ideal entry points for newcomers like myself. These labels serve as beacons for code changes that are not only manageable but also self-contained, providing a perfect starting ground for someone newly acquainted with the project. In this way, I aimed to ensure that my initial contribution would be a positive and constructive addition to the PyTorch codebase. The "good first issue" label became my compass, guiding me toward an opportunity to make a meaningful impact while acclimating to the intricacies of the PyTorch ecosystem. 🌱👩‍💻🔍

I chose this issue: https://github.com/pytorch/pytorch/issues/113198

It was really easy to replicate the error, and there was already a minor discussion about the starting point and some strategies.

The bug was because, for CUDA tensors, a user couldn't call a pow function using Tensor and Boolean as arguments. It was generating an error message about that.

In [52]: torch.pow(torch.tensor([1, 2]), True)
Out[52]: tensor([1, 2])

In [53]: torch.pow(torch.tensor([1, 2], device='cuda'), True)
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
Cell In[53], line 1
----> 1 torch.pow(torch.tensor([1, 2], device='cuda'), True)

RuntimeError: false INTERNAL ASSERT FAILED at "/home/isuruf/git/pytorch/aten/src/ATen/native/cuda/PowKernel.cu":199, please report a bug to PyTorch. invalid combination of type in Pow function, common dtype:Longexp is integral?0

The maintainer wanted just to disable this possibility because sending a boolean as an exponent is kind of strange, to say the least.

However, other people with the same issues were discussing that they were expecting the same already existing behaviour considering CPU tensors. Also removing this possibility could cause some compatibility breaks.

Reading through Python's official documentation, I discovered that booleans in Python are a subtype of integers, so it actually made sense that someone would try to use them as an integer exponent.

The last thing to convince me that this would be a good idea was:

x=True
x+x
2

So I decided to write code to support a boolean as an argument, even if the maintainer wanted the opposite. As it would be a minor change, I didn't mind writing the code to bring this discussion. Sometimes, I think it's better to start a discussion with a working code to showcase the solution and its implications. It worked out in the end! 😉

Starting to work

Compiling PyTorch

So, kicking off any software gig involves just building the darn thing as is; no tweaks are allowed. 🏗️ Sounds easy, right? Well, hold your horses! It's like trying to tame a wild beast because software projects are this crazy maze of environments and dependencies. 🤯 Getting that baseline set without messing around is a bit like laying the groundwork for an epic adventure. You gotta grasp all the nitty-gritty stuff before diving into the cool customization part. This seemingly basic step is actually a secret weapon—it’s the key to tackling all the twists and turns in the software jungle. 🌐✨

Compilation instructions

https://github.com/pytorch/pytorch#from-source

I won't repeat their instructions here because that is subject to change, and then whatever I write here will become obsolete.

Just remember, use conda because it will definitely make your life easier.

When you finally type python setup.py develop, be prepared to wait for some hours if you're using your personal computer. Unless you have a really high-end machine, that is going to take a while. Cross your fingers that you have more luck than me and that everything goes great so you don't have to start all over again.

Problem with GCC13

My First problem was that it wasn't working for gcc13 for some CUDA code. So, I had to install gcc12 and set CC and CXX for gcc12.

I don't remember exactly what it was at the time, but here's a thread from May 2023 that it's on my web history. I wonder if my errors were the same...who knows? :)

https://forums.developer.nvidia.com/t/strange-errors-after-system-gcc-upgraded-to-13-1-1/252441/9

Anyway, that was just a matter of installing GCC12 and setting CC and CXX accordingly:

yay -S gcc-12
export CC=gcc-12
export CXX=g++-12

And then compilation went ahead.

Build was failing for tests

I also had to set BUILD_TESTS=OFF because tests were not compilating right.

Below is the file where I found all those flags and its description. I highly recommend always looking because you can always find something useful. Sometimes, you just want to disable something so you can save some compilation time.

https://github.com/pytorch/pytorch/blob/main/setup.py

GLIBC problem

I was having this error: libstdc++.so.6: version GLIBCXX_3.4.32

Then I had to update my glibc with Conda. I think this might be related to my default GCC being GCC13 within my OS.

But to fix that, I did the following:

conda install -c conda-forge libstdcxx-ng

I never thought that conda would have a repository that had generic dependencies, as in packages that are not directly related to Python. That is indeed an amazing tool. And now, more than even, I understand why Python has so good package managers and environment switchers. It's because it only works if everything is meticulously tightened to the same version or everything will fall apart.

Smoke test

After my first compilation success, my smoke test was just opening python in the PyTorch folder and checking if import torch was working. As I don't have pytorch somewhere else in my machine, if that line worked, I knew that my first step was done! 💪

Changing code

Embarking on large software projects for the first time can feel like diving into a code labyrinth—daunting and disorienting. Navigating through the intricacies of an expansive codebase without a roadmap can be a real head-scratcher. Having a starting point handed to you is like finding a treasure map; it might not lead you directly to the X, but it sure beats aimlessly wandering through the code wilderness. Imagine trying to trace changes from the main function—it's like a quest with no end in sight! Getting a hint or a guide in the right direction can be a game-changer, turning what seems like an impossible task into a manageable adventure. 🗺️🕵️‍♂️

So my treasure map was given by a maintainer in the issue's comment section. It was called native_functions.yaml.

You can think of this file as an API descriptor of Pytorch. All the functions that are exported for the user, on Python or C++, must be described in this YAML file.

More info about its description and format: https://github.com/pytorch/pytorch/tree/main/aten/src/ATen/native#readme

As I was trying to fix the pow function, I went into this file looking for pow, and then I found this block:

- func: pow.Tensor_Scalar(Tensor self, Scalar exponent) -> Tensor
  device_check: NoCheck   # TensorIterator
  structured_delegate: pow.Tensor_Scalar_out
  variants: function, method
  dispatch:
    SparseCPU, SparseCUDA: pow_sparse_scalar
  tags: [core, pointwise]

A skilled software developer should embrace rather than fear the challenge of delving into unfamiliar code and definitions. It's a crucial skill to be able to decipher and understand written code, even when it's initially unfamiliar. The ability to glean insights just by glancing at the code is like having a superpower—it allows you to confidently navigate complex systems.

For this particular case, you can see that it has the same arguments as my broken pow function (Tensor and a Scalar) and returns a Tensor. I have no idea what structured_delegate means, to be honest, I still don't 😅. But I just figured that this pow.Tensor_Scalar_out could be the function that I was looking for, and I was godd*mn right

I found this function implementation on cpp/Pow.cpp:

TORCH_IMPL_FUNC(pow_Tensor_Scalar_out) (const Tensor& base, const Scalar& exp, const Tensor& out) {
  if (exp.equal(0.0)) {
    out.fill_(1);
  } else if (exp.equal(1.0)) {
    out.copy_(base);
  } else {
    pow_tensor_scalar_stub(device_type(), *this, exp);
  }
}

After identifying an issue in the code, I needed to implement a fix. The problem was with the CUDA kernel, but upon examining the code, I noticed that for exponents 0 and 1, they didn't go into CUDA because it was trivial. For exponent=0, the results were always 1, and for exponent=1, it was the same value. Therefore, I decided to maintain this behavior, as there's always overhead involved in calling the kernel. As native Python treats True as 1 and False as 0, I modified the code to the following:

TORCH_IMPL_FUNC(pow_Tensor_Scalar_out) (const Tensor& base, const Scalar& exp, const Tensor& out) {
  if (exp.equal(0.0) || exp.equal(false)) {
    out.fill_(1);
  } else if (exp.equal(1.0) || exp.equal(true) ) {
    out.copy_(base);
  } else {
    pow_tensor_scalar_stub(device_type(), *this, exp);
  }
}

After fixing I built my code again and tested if my changes did something recreating the scenario that the ticket creator has tried. Great success, no error message anymore!

Python 3.12.0 | packaged by Anaconda, Inc. | (main, Oct  2 2023, 17:29:18) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> torch.pow(torch.tensor([1, 2], device='cuda'), True)
tensor([1, 2], device='cuda:0')
>>> torch.pow(torch.tensor([1, 2]), True)
tensor([1, 2])
>>> torch.pow(torch.tensor([1, 2]), False)
tensor([1, 1])
>>> torch.pow(torch.tensor([1, 2], device='cuda'), False)
tensor([1, 1], device='cuda:0')

Submitting the PR

Preparation

Before diving into open source contribution, it's imperative for every aspiring contributor to thoroughly read and understand the community guidelines. These guidelines serve as the holy grail, outlining standards and instructions ranging from formatting commit messages to the nuances of crafting a PR. They detail essential information, such as required tests, legal obligations, and the community's code of conduct. Ignoring these guidelines is akin to starting a journey on the wrong foot, especially in the realm of open source where community is paramount. Trust is the bedrock of open source collaboration, and maintainers, often inundated with review requests and issues, rely on contributors to adhere to established norms. Missing a crucial step could lead to your PR being overlooked indefinitely. Therefore, approaching open source with humility, attentiveness, and a commitment to following guidelines is key—read, comprehend, and don't hesitate to seek clarification if needed. Your contributions will be all the more impactful when aligned with the community's expectations. 🌐💡

For Pytorch there's:

PR experience

After everything I just went there and created my PR from personal branch. In my humble opinion, just go there, present yourself briefly be as polite and objective as you can.

Follow the standard PR message. For PyTorch you must mention your issue with Fixes XXXX. Explain your code decisions, show at least that you tested something. And be open-minded and patient, a maintainer will review your code and be prepared to criticism and don't take it personally. It's possible that you think your approach is the best one and you might be right but always respect the maintainer opinion and if he asks to change something even after your argumentation, drop your PR or make the change. Maintainers have final word for a reason, they have been there for a long time and you won't imagine the different scenarios they have seem before, they probably have a reason to deny some codes and have little to zero time to explain why they will.

Back to the experience I was asked to create a test for my PR. Something that I had some trouble to understand but eventually I did 😅.

PyTorch has a complex test framework that is written because of many scenarios and devices that they need to test. Is related to some annotations about what devices, input, and operations that you would like to test.

Explanation is within this file: https://github.com/pytorch/pytorch/blob/main/torch/testing/_internal/common_device_type.py

For my case I just had to find the pow test and add True and False as exponents on the test input and everything was done.

As I created my PR there was another person that sent me an e-mail saying that he was working on the same issue asking to work together. I added him as a co-author because it was the right thing to do for his courtesy.

PR approved! 🎉

Check for boolean values as argument on pow function. #114133

pdrocaldeira posted on Nov 20, 2023

Hello everyone! 😄 Also @lezcano , nice to meet you! :)

Sorry if I miss anything, this is my first time around here. 🙃

This PR basically makes the same behaviour for cuda when using torch.pow. Basically Python considers True as 1 and False as 0. I just added this check into pow function. From what I understood, when I do .equal for Scalar that is boolean, I'm sure that types match so that won't cause more trouble.

I know that the issue suggest to disable this case but that could be a little more complicated, in my humble opinion. And that can create some compability problems too, I guess.

My argument is that code below is correct for native language, so I guess it does makes sense sending booleans as Scalar.

$ x = True
$ x + x
2

This was my first test:

Python 3.12.0 | packaged by Anaconda, Inc. | (main, Oct  2 2023, 17:29:18) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> torch.pow(torch.tensor([1, 2], device='cuda'), True)
tensor([1, 2], device='cuda:0')
>>> torch.pow(torch.tensor([1, 2]), True)
tensor([1, 2])
>>> torch.pow(torch.tensor([1, 2]), False)
tensor([1, 1])
>>> torch.pow(torch.tensor([1, 2], device='cuda'), False)
tensor([1, 1], device='cuda:0')

I've run test_torch.py and got following results, so my guess is that I didn't break anything. I was just looking for a test that uses linear regression, as suggested.

Ran 1619 tests in 52.363s

OK (skipped=111)
[TORCH_VITAL] Dataloader.enabled         True
[TORCH_VITAL] Dataloader.basic_unit_test         TEST_VALUE_STRING
[TORCH_VITAL] CUDA.used      true

(I can paste whole log, if necessary)

If this is a bad idea overall, dont worry about it. It's not a big deal, it's actually a two line change 😅 so can we talk of how do things in a different strategy.

For the record I've signed the agreement already. And I didn't run linter because it's not working 😞 . Looks like PyYaml 6.0 is broken and there's a 6.0.1 fix already but I have no idea how to update that 😅

Fixes #113198

View on GitHub

Modernizing Legacy Code with Gradle: A Seamless Integration Journey

Pedro Caldeira — Sun, 19 Nov 2023 21:14:35 +0000

Introduction to Gradle

Gradle, a powerful build automation tool, has become a cornerstone in modern software development. Its flexibility, scalability, and plugin-based architecture make it ideal for managing complex build processes. This blog post explores my experience integrating a more than a decade-old codebase with Gradle, highlighting the simplicity and effectiveness of the process.

Navigating a Decade-Old Codebase

The need for a robust build system becomes evident when faced with the challenge of integrating legacy code. Gradle provides a solution that streamlines the integration process, enabling developers to modernize their projects efficiently.

Managing Multiple Main Classes with Ease

One notable feature of Gradle is its seamless handling of projects with multiple main classes. Configuring the main class to be used is straightforward:

application {
    mainClassName = 'com.example.MainClass'
}

This simplicity ensures that the correct entry point is invoked during application execution.

Effortless Dependency Management

Gradle simplifies the addition of dependencies with a concise syntax. Declaring dependencies is as easy as specifying the group, name, and version:

dependencies {
    implementation 'group:artifact:version'
}

This straightforward approach enhances code maintainability and readability.

Enforcing Java Version Compatibility

Ensuring compatibility with a specific Java version is a breeze in Gradle. By setting the Java version in the build script, developers can avoid compatibility issues:

java {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
}

Configuring the Runtime Environment

Adapting the runtime environment to accommodate configuration files is effortlessly achieved with Gradle. Adjusting the working directory allows for seamless access to configuration files:

run {
    workingDir = file('config-files-directory')
}

Customizing Application Execution with Args

Gradle facilitates the customization of application execution by allowing the inclusion of custom arguments:

run {
    args 'arg1', 'arg2'
}

This flexibility empowers developers to tailor the runtime behavior according to their specific requirements.

Conclusion

Integrating legacy code with Gradle proved to be a remarkably smooth journey. The streamlined syntax, extensive documentation, and vibrant community support make Gradle an invaluable tool for any developer looking to modernize and enhance their projects. I only wish I had made the switch sooner, as Gradle's user-friendly approach made every step of the process a joy.

Mastering Consistency: Leveraging Git Commit Templates for Unified Team Commit Messages

Pedro Caldeira — Mon, 13 Nov 2023 14:55:02 +0000

Introduction

In the realm of collaborative coding, the harmony of a team lies not only in the lines of code but in the consistency of communication. Git commit messages, often the unsung heroes of version control, play a pivotal role in understanding the evolution of a codebase. Ensuring these messages follow a unified structure can be a game-changer for teams striving for coherence and clarity. Moreover, standardized commit messages become crucial, as they might be parsed to comply with company standards, transcending mere organization to align with broader corporate requirements. This blog explores the power of Git commit templates in fostering a shared language within a team, ensuring compliance with both internal standards and the facilitation of a seamless understanding of the project's development history.

Context

I've encountered numerous instances where I've overlooked the prescribed company standard for commit messages. In the rush of coding and the flurry of changes, omitting something as minor as a semicolon or missing a specific format happens all too easily. It's these moments that disrupt the flow, sending me on a scavenger hunt through documents or repositories to retrieve the correct format. The process of fixing the commit message, pushing with force, and rectifying the error becomes a detour, stealing both time and focus from the actual task at hand. These interruptions, seemingly small, can snowball into significant distractions, impeding productivity and the seamless progression of work.

Steps

To overcome this hiccup I deciced to step my git skills a little bit up and decide to set my pre-commit-msg with a template that will just print for me how the standard commit message should be with a brief explanation of every section.

For example, I created a .gitmessage within my dotfiles folder and created a link for it to be at home folder as well.

Then I just ran git config --global commit.template ~/.gitmessage

This makes this template default for all repositories for my user. That's not a problem for me as this machine I use only to code for my employee that uses same standard between every project.

It's possible to create a definition for each project but this is out of scope for this post. But I bet it's just a matter to create a local hook inside the project folder.

My .gitmessage looks like this:

#Mandatory Format:
#GITHUBID: [TYPE] MESSAGE
#
#TYPE    : Is one of the following:
#            feat     : new feature
#            fix      : bug fix
#GITHUBID    : GITHUB issue ID.
#MESSAGE : Brief description of the change.

Result

Now everytime I do a git commit it will write my chosen template message below where I should write my actual commit message.

#Mandatory Format:
#GITHUBID: [TYPE] MESSAGE
#
#TYPE    : Is one of the following:
#            feat     : new feature
#            fix      : bug fix
#GITHUBID    : GITHUB issue ID.
#MESSAGE : Brief description of the change.

Future improvements

With this I can only have the template easily at my screen exactly when I need it so I can't forget about it. However I still need to look some info outside, for example my Github Issue ID.

One idea for the future is to just have this Issue ID while I create my new branch or something like that. Then I can parse that using an local environment variable or something like that. I will probably need another hook for changing branches.

I saw some solutions that creates working branch with issue ID already and then just parses it when committing. Personally I don't like this idea because I like to have my branches with actual meaningful titles so I don't have to open github to know what they were.

Forem: Pedro Caldeira

Exploring Python Environments with PyEnv

Introduction

Installing pyenv

Basic Operations

Listing Available Python Versions

Installing a Python Version

Setting the Global Python Version

Creating a Virtual Environment

Activating and Deactivating Environments

Advanced Usage with the Virtualenv Plugin

Creating Virtual Environments with the Plugin

Activating and Deactivating Environments with the Plugin

Listing Virtual Environments

Understanding pyenv local, pyenv global, and pyenv shell

1. pyenv local

2. pyenv global

3. pyenv shell

Focus on pyenv local

Conclusion

Resources

Transitioning from Docker to Podman: Navigating Challenges and Practical Solutions

Introduction

Docker Overview

Podman Overview

Context

Exploring Podman

Aliasing for Seamless Transition

Daemonless Operation

Addressing Permission Denied Issues

Conclusion

Diving into the Deep: My Inaugural PyTorch Contribution Adventure!

Context

Finding an issue

Starting to work

Compiling PyTorch

Compilation instructions

Problem with GCC13

Build was failing for tests

GLIBC problem

Smoke test

Changing code

Submitting the PR

Preparation

PR experience

Check for boolean values as argument on pow function. #114133

Modernizing Legacy Code with Gradle: A Seamless Integration Journey

Introduction to Gradle

Navigating a Decade-Old Codebase

Managing Multiple Main Classes with Ease

Effortless Dependency Management

Enforcing Java Version Compatibility

Configuring the Runtime Environment

Customizing Application Execution with Args

Conclusion

Mastering Consistency: Leveraging Git Commit Templates for Unified Team Commit Messages

Introduction

Context

Steps

Result

Future improvements

References

Installing `pyenv`

Understanding `pyenv local`, `pyenv global`, and `pyenv shell`

1. `pyenv local`

2. `pyenv global`

3. `pyenv shell`

Focus on `pyenv local`