GSoC 25– Modernisation of vcstool with Open Robotics


Google Summer Season of Code 2025 with ROS Facilities Group at Open Robotics

What is vcstool?

vcstool is a command-line tool utilized to handle multiple version control systems (VCS) simultaneously. These consist of Git , Subversion , Mercurial and the freshly migrated Windy (previously known as Exchange).

This device is widely preferred among the robotics software community for dealing with tasks that are composed of numerous different, independent repositories.

The Core Issue It Solves

Allow’s claim that you have a robotics project containing 50 databases that handle various software program elements (motorists, libraries, understanding formulas, etc). Manually running git pull , git condition , or git check out in each of these 50 folders would certainly be incredibly tedious and error-prone.

vcstool resolves this by permitting you to do these operations on all databases with a single command. Its key feature is to perform commands such as draw , status , import , export , diff , etc, across numerous repositories at once.

Objectives of the Contribution Period

Sadly, vcstool has not been actively maintained for a few years, making it breakable and more challenging to maintain as a reliance of other ROS infrastructure tooling. The goal of this job is to bring the tool to a modern-day Python application and start dispersing this fork to the area.

The project is now forked under ROS Framework with some popular feature demands ported over from its parent repository. Ultimately, neighborhood contributions to this fork are highly encouraged and welcomed.

Furthermore, a careful port of the deprecated vcstools (with a tracking’s’) API is required to supply active assistance with Flower.
Blossom is a preferred ROS device that automates the process of releasing a source code plan right into installable Debian bundles for the main ROS repositories.

The last action is to release an extensive website that records the API and command structure.

On the whole, this is a checklist of the goals that were targeted during this payment period:

Key Goals

  1. Fork from vcstool and relabel the project to vcs 2 l.
  2. Add support for contemporary Python and deal with deprecation warnings.
  3. Release and disperse this new plan with PyPI and as a Debian.
  4. Address enduring area feature/bugfix requests.

Stretch Goals

  1. Enhance documentation for vcstool use by releasing an in-depth website overview for its API.
  2. Boost payment and repository standards through themes for Protection, Code of Conduct and DCO.
  3. Replace vcstools with this brand-new fork in bloom and vcstool in the ros_buildfarm manuscripts.
vcs 2 l sustained at ROS Infrastructure Team

Personal Contributions to the Task

There are a total amount of four releases and a forthcoming fifth release that have actually emerged from the job. The complying with describes the prominent features throughout these various launches.

Turning point 1 — 1 1.0 , 1 1 1 , and 1 1 2 Launches

  1. Take care of the testing operations to securely work on Ubuntu, Mac, and Windows subsystems. In addition, move all the GitHub activities to be pinned to their hashes for security toughness.– # 2
  2. Among the targets of this milestone was to relabel the task from vcstool to vcs 2 l. This offers necessary distinction upon launch to PyPI and releasing the Debian package.– # 16
  3. Prolong assistance to Python 3 5 + variations in order to offer compatibility to Debian Buster, RHEL 8, and Ubuntu Focal. This results from the fact that these circulations are still sustained by ROS 2 Humble.– # 19
  4. Usage preferred pre-commit hooks to stop vacant whitespace and extra newlines from registering as a different dedicate throughout development. Furthermore, codespell was contributed to stop documentation mistakes as part of the operations.– # 6 and # 11
  5. Deprecate pkg_resources in favour of importlib.metadata for more recent versions of Python. This change was inspired by the persistent cautions of the existing state of vcstools.– # 4
  6. Added detailed descriptions to the setup.py file to suggest the individual of the current proprietor (ROS Facilities Team).
    These include inhabiting the touchdown web page of the PyPI release to reveal the database’s README , adding advancement condition to the Chest’s Classifiers and including keyword phrases to raise the repository’s exposure.
    # 16

Milestone 2– 1 1 3 Release

  1. Deprecate the hand-operated flake 8 linter manuscript and utilize the Ruff linter by Celestial for standardisation of contemporary linting. Base Ruff configuration consists of PyFlakes, ISort and a preference for solitary quotes for format.– # 27
  2. Added Dependabot for GitHub Activities to maintain track and update all the ingrained matching actions to the most recent and secure variation.– # 28
  3. Included payment templates for insect reports, function requests and pull requests. Additionally, Clara and I were added as Codeowners to the repository for timely customer responses.– # 23
  4. Reorganisation of the CI workflow to run only on pull demands and presses to the default branch. Additionally, an energetic migration for the branch rename has actually been done from master to primary # 29
  5. Included the capacity for vcs import to retry bring the pick repository upon failing. This is especially beneficial when working with systems that have an inadequate network connection, so that the importing of repositories does not quickly fail.– # 34
  6. Added debug support for missing out on keys in the checklist of databases data. This supplies the user important details if they have a missing out on link, variation control kind or both. Combination examinations have been added to evaluate the credibility of this adjustment.– # 35

Existing State of the Task

The task is currently on its 3rd landmark, targeting the pending function demand ports from its initial fork. The following is the present state of the repository under this release.

vcs 2 l 1 1 3 at PyPI

Landmark 3– 1 1 4 Release (Underway)

Merged

  1. Ensured the ability of the output exported documents to be formatted using yamllint for standardisation. This is allowed using the -- dust flag on export.
    In addition, this linter is included in the whole repository, making certain rigorous compatibility across the codebase.– # 33
  2. Added Python 3 7 and 3 8 to the testing process to make sure added adjustments are not divergent in order to make sure backwards compatibility.
    # 37
  3. Enabled Subversion and Unstable to operate on the CI for screening. This screening compatibility is reached Ubuntu and macOS.
    On top of that, a valid Subversion database has been added to the vcs confirm examination, dealing with the damaged link prior.– # 42

In Review

  1. Adding a manual launch operations that stores the wheel and tar.gz artifacts upon launch. This would certainly likewise post to PyPI promptly when the operations is linked to the publishing pipeline of the vcs 2 l PyPI database.– # 36
  2. Assistance for inheritance has actually been included so that a single repository documents can import from a list of picked moms and dad repositories. This is to reduce import documents interpretation and to stop redefining the very same databases, which can be acquired rather.– # 39
  3. Included a choice to erase a selection of directory sites from a repository arrangement data by introducing a remove flag.
    The remove command offers the individual with debug details concerning the directory sites that will certainly be removed. It does not explicitly eliminate them up until a -- pressure flag is supplied.– # 40
  4. Consisted of guidelines for Code of Conduct and Security in the codebase. On top of that, details regarding the Developer Certification of Origin has actually been added to the Adding overview.
    This additionally improves the database’s presence by satisfying all the suggested GitHub community standards.– # 24 and # 44
  5. The careful port of vcstools has actually been included with export_repository and check out functions. This has actually been consisted of in all four supported VCS– git , svn , hg , and bzr
    This has actually been gone along with by comprehensive combination examinations and Windy screening sustained in CI.– # 43

Future Work

Besides recurring support with the pull requests that are In Review, right here are a few of the pending attributes that are yet to be consisted of in the codebase:

  1. Allowing assistance for pinning submodules to a specific hash upon exporting with the -- nested flag.
    Presently, this pipe does not identify submodules despite the flag allowed. Hence, a detailed effort is needed to allow this function.
  2. Consisting of codecov as part of the screening workflow would make it possible for the end customer to identify the degree of the efficiency of the examinations attached and establish a criterion of payments that include durable examinations.
  3. Posting a thorough documentation pertaining to using each supported command is still pending.
    In addition, a tutorial overview can be consisted of to aid the individual obtain a much better understanding of each facet of vcs 2 l.
  4. The substitute of the bundle has not been ported over to the ros_buildfarm scripts. This must be done in the next upcoming release of the database.

Challenges encountered throughout the contribution

There were a couple of discovering contours that I had to encounter during my payment period; nevertheless, these proved to be a significant training moment for me and enabled me to end up being a better software designer.

  1. Considering that vcs 2 l drops under the ROS Facilities group, I was welcomed to join a regular PMC (Job Meeting Committee) meeting.
    The initial weeks confirmed to be challenging in recognizing the roles of various other developers in the team and their corresponding obligations.
    However, as the weeks passed, the framework of the PMC meeting and the cooperation procedure verified to be less complicated to understand.
  2. Figuring out the launch operations of bundles under the ROS infrastructure confirmed to be difficult. I was not aware of the standardised launch procedure, that included the launch to the bootstrap repositories and the ros_release_python operations.
  3. Understanding the safety facet of keeping an active codebase was absolutely unique to me. The approach of pinning dedicate hashes of GitHub Actions and limiting the Debian release process to trusted participants of the ROS Facilities Group to maintain safety and security was among the paradigms that I was not knowledgeable about.

Recognitions and Post-GSoC Work

I wish to thank my mentor, Clara Berendsen Pereira , for her ongoing assistance and undeviating support throughout this process. I would certainly additionally like to thank Steven! Ragnarök for actively aiding each release.

Furthermore, I would like to say thanks to Christophe Bourque Bédard and Jose Luis Rivero for assessing my pull demands completely and providing active responses.

Finally, I am thankful to the rest of the participants at the ROS Facilities PMC for freely discussing my concepts at the weekly conference and offering useful suggestions relating to the stability of my proposed remedies.

I am likewise honoured to be part of the organisation as a main committer mentee for the project. I anticipate following up on the future work of the database and maintaining it for times to come.

Links

  1. Job Summary
  2. Project Proposal
  3. vcs 2 l– PyPI
  4. Parent database– dirk-thomas/vcstool
  5. Project/Forked repository– ros-infrastructure/vcs 2 l
  6. Merged Pull Demands
  7. Open Up Pull Requests

Socials

If you want to know even more regarding the project and its succeeding execution, feel free to reach out to me at:

Source link

Leave a Reply

Your email address will not be published. Required fields are marked *