Software package synchronization method and device and program item synchronization method

Abstract

The invention provides a software package synchronization method, which utilizes templates to synchronize software packages of different scene program projects, and comprises the following steps: obtaining a target software package of a target scene program project and a corresponding software package record file, the software package recording file records a template identifier and a template version used when the target software package is generated; wherein the software package is generated based on the template version of the reference template; according to the template identifier, determining the reference template corresponding to the target software package; comparing the current version of the reference template with the template version, and checking whether difference content exists or not; and if the difference content exists, synchronizing the difference content to a target software package of the target scene. The invention further provides a corresponding device and program item synchronization. According to the application, accurate mapping between a plurality of target software packages and software package versions can be established in robot application program development under multiple application scenes, and batch updating of the software packages is realized.

Description

Technical Field

[0001] This application relates to the technical field of software development and version control, and in particular to a software package synchronization method, apparatus, and program project synchronization method. Background Technology

[0002] In the field of robot software development and application, robot applications typically consist of multiple collaborative software packages and nodes. When a single robot or robot of the same model needs to be adapted to various application scenarios, such as during the robot application development and testing phase, developers often need to perform a large amount of repetitive code modifications to test its performance in various scenarios. This process is tedious and inefficient.

[0003] Existing technologies widely use ROS2 (Robot Operating System 2) as the code framework for robot application development. While it provides a basic mechanism for centralized management of software packages, it still has significant shortcomings when dealing with complex development needs involving multiple scenarios and versions. Specifically, in multi-application scenarios, upgrading and updating the basic functions of software packages requires either pushing to the target software package one-to-one or directly modifying each target software package individually, resulting in low maintenance efficiency and the risk of errors. Furthermore, due to the inability to effectively map different software package versions, it lacks project-level batch update capabilities.

[0004] Therefore, in this context, how to establish a precise mapping between multiple target software packages and software package versions in the development of robot applications in multiple application scenarios, and realize batch updates of software packages, is a technical problem that needs to be solved. Summary of the Invention

[0005] In view of the above-mentioned problems of the prior art, this application provides a software package synchronization method, device and program project synchronization method, so as to establish a precise mapping between multiple target software packages and software package versions in the development of robot applications in multiple application scenarios, and realize batch updates of software packages.

[0006] To achieve the above objectives, the first aspect of this application provides a software package synchronization method, which uses a template to synchronize software packages of program projects in different scenarios. The method includes: Obtain a target software package and its package record file for the target scenario program project. The package record file records the template identifier and template version used when generating the target software package. The software package is generated based on a template version of a baseline template. Based on the template identifier, determine the baseline template corresponding to the target software package; Compare the current version of the benchmark template with the template version to check for differences; if differences exist, synchronize the differences between the current version of the benchmark template and the target software package to the target software package of the target scene; wherein, the differences are the parts of the current version of the benchmark template that are inconsistent with the content of the target software package.

[0007] As described above, the target software package is generated based on a template version of the baseline template, enabling the software packages used in each target scenario to be mapped to the baseline template. A software package record file records the corresponding baseline template (template identifier) ​​and template version, saving template information at the time of generation or update. When an updated version of the baseline template exists, it can be identified through template version comparison, thereby synchronizing the differences. Since multiple target software packages are created based on the same baseline template, only one modification to the baseline template is needed to achieve update synchronization of multiple target software packages, thus enabling batch updates of target software packages in robot application development across multiple application scenarios.

[0008] As one possible implementation of the first aspect, the baseline template is generated in the following manner: Obtain the reference software package for the reference scenario; Replace the parameterized content in the reference software package file with template variables, and generate the baseline template; Each time the baseline template is modified, the modified baseline template is submitted to the template repository, and an independent template version is generated and stored together. Retrieve the current version of the baseline template from the template repository.

[0009] As described above, by parametrically modifying the reference software package to form a reusable baseline template, and by generating independent template versions, a template repository is built for version management, so that the specific baseline template and template version can be accurately located during synchronization.

[0010] As one possible implementation of the first aspect, the software package log file further includes template parameters, which synchronize the differences between the current version of the baseline template and the target software package to the target software package of the target scenario, including: The portion of the difference content involving template variables is replaced with the corresponding template parameters recorded in the package log file to generate updated content adapted to the target package; wherein, the template variables are the parameterized content in the base template that needs to be replaced; The updated content will be synchronized to the target software package in the target scenario.

[0011] As described above, by replacing the parts involving template variables in the difference content with the differentiated template parameters of each target software package, it is ensured that the specific configurations of each target software package for its own scenario are retained and reused on the basis of the baseline template, so as to realize the rapid creation and modification of software packages in multiple application scenarios.

[0012] As one possible implementation of the first aspect, the target software package includes at least one of the following directories or files: main function code directory, resource file directory, software package record file, and configuration file; The baseline template corresponding to the target software package includes at least one of the following directory or file templates: main function code directory template, resource file directory template, software package record file template, and configuration file template.

[0013] In addition to the main function code directory and resource file directory, the generation of package log files and configuration files can be uniformly updated and managed through package log file templates and configuration templates, thereby improving the automation level of package synchronization and avoiding the tedious work of manually configuring package log files and configuration files repeatedly.

[0014] As one possible implementation of the first aspect, the file path of the baseline template or the template repository is absolute; During software package synchronization, the baseline template is obtained either by using an absolute file path or from the template repository with an absolute file path.

[0015] As shown above, in complex environments involving multi-repository collaboration or distributed template storage, relative path references may fail due to differences in working directories or storage structures. By making the file paths absolute, restrictions on the directory structure of the template repository are avoided, thus improving compatibility with the template repository.

[0016] A second aspect of this application provides a method for synchronizing a program project, the program project comprising at least two target software packages, wherein at least two target software packages are updated via batch processing, the method comprising: Obtain the list of target software packages that need to be synchronized in the program project; wherein, the list of target software packages includes the target software packages that need to be synchronized and their package record files; The list is traversed, and for each target software package and its package record file in the list, the software package synchronization method described in the first aspect is executed sequentially to complete the synchronization update of the program project.

[0017] As described above, by obtaining the list of target software packages that need to be synchronized in the program project, the program project can be selectively updated or fully updated according to the update requirements of the application scenario. By iterating through each target software package in the target software package list using the software package synchronization method in the first aspect, the batch synchronization and update of the target software packages of the entire program project is realized, which greatly improves the overall maintenance efficiency of the robot software system.

[0018] As a possible implementation of the second aspect, it also includes directory-level synchronization of the program project, specifically including: The target software package list is mapped and compared with the current baseline template list obtained from the template repository; If a new software package benchmark template exists in the current benchmark template list, a new software package is created based on the new software package benchmark template and added to the program project; If a target software package no longer has a corresponding benchmark template in the current benchmark template list, then the target software package is removed from the program project.

[0019] Therefore, when a full update is performed at the program project level, even if the structure of the program project is modified, such as adding or deleting software packages, a convenient and automated synchronization update can be performed to ensure that the structure of the program project is always consistent with the current template list structure.

[0020] A third aspect of this application provides a software package synchronization device, comprising: The scene information acquisition module is used to acquire a target software package and its software package record file of the target scene program project. The software package record file records the template identifier and template version used when generating the target software package. The software package is generated based on a template version of a baseline template. The template determination module is used to determine the baseline template corresponding to the target software package based on the template identifier; The software package update module is used to compare the current version of the benchmark template with the template version to check for differences; if differences exist, the differences between the current version of the benchmark template and the target software package are synchronized to the target software package of the target scenario; wherein, the differences are the parts of the current version of the benchmark template that are inconsistent with the content of the target software package.

[0021] A fourth aspect of this application provides a computing device, including: a processor and a memory storing program instructions thereon, the program instructions, when executed by the processor, causing the processor to perform the software package synchronization method of any one of the first aspects and the program item synchronization method of any one of the second aspects.

[0022] The fifth aspect of this application provides a computer-readable storage medium having program instructions stored thereon, which, when executed by a computer, cause the computer to perform the software package synchronization method of any one of the first aspects and the program item synchronization method of any one of the second aspects.

[0023] The sixth aspect of this application provides a computer program product including program instructions that, when executed by a computer, cause the computer to perform the software package synchronization method of any one of the first aspects and the program item synchronization method of any one of the second aspects. Attached Figure Description

[0024] Figure 1 This is a flowchart of the software package synchronization method provided in the first embodiment of this application; Figure 2a This is a flowchart of the software package synchronization method provided in the second embodiment of this application; Figure 2b This is a flowchart illustrating the creation and updating of the software package template provided in the second embodiment of this application; Figure 2c This is a schematic diagram of the modified software package template provided in the second embodiment of this application; Figure 3 This is a flowchart of the program project synchronization method provided in the second embodiment of this application; Figure 4 This is a schematic diagram of the software package synchronization device provided in the embodiments of this application; Figure 5 This is a schematic structural diagram of a computing device provided in an embodiment of this application.

[0025] It should be understood that the dimensions and shapes of the blocks in the above structural diagrams are for reference only and should not constitute an exclusive interpretation of the embodiments of the present invention. The relative positions and inclusion relationships between the blocks presented in the structural diagrams are only schematic representations of the structural relationships between the blocks, and are not intended to limit the physical connection methods of the embodiments of the present invention. Detailed Implementation

[0026] The technical solutions provided in this application will be further described below with reference to the accompanying drawings and embodiments. It should be understood that the system architecture and business scenarios provided in the embodiments of this application are mainly for illustrating possible implementations of the technical solutions of this application and should not be construed as the sole limitation on the technical solutions of this application. Those skilled in the art will recognize that the technical solutions provided in this application are equally applicable to similar technical problems as system architectures evolve and new business scenarios emerge.

[0027] It should be understood that the software package synchronization schemes provided in the embodiments of this application include software package synchronization methods, apparatuses, program project synchronization methods, computing devices, computer-readable storage media, and computer program products. Since these technical solutions solve problems based on the same or similar principles, some repetitive details may not be repeated in the following descriptions of specific embodiments. However, it should be considered that these specific embodiments have mutual references and can be combined with each other.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. In case of any inconsistency, the meaning set forth in this specification or derived from the content described herein shall prevail. Furthermore, the terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application. To accurately describe the technical content of this application and to accurately understand the invention, the following explanations or definitions of the terms used in this specification are provided before describing specific embodiments: 1) Robot Operating System (ROS / ROS2): An open-source meta-operating system and development framework for robot software development. It provides a series of software libraries, tools, and conventions designed to simplify the creation of complex and robust behaviors on various robot platforms, supporting hardware abstraction, low-level device control, implementation of common functions, inter-process message passing, and package management.

[0029] 2) Software Package: In the ROS system, a software package refers to an independent functional module that contains an executable program (node), libraries, configuration files, build files, and manifest files (such as package.xml). It is the basic unit for code organization, building, and distribution in ROS, and usually corresponds to a specific robot function.

[0030] 3) Node: In the ROS system, a node is an independent executable process responsible for performing specific computational tasks. Nodes communicate with each other through methods such as publishing / subscribing to topics or requesting / responding to services, collectively forming a distributed robot software system.

[0031] 4) Workspace: A directory structure containing ROS packages, used to organize, compile, and develop one or more related ROS packages. It typically contains subdirectories such as src (source code), build (build files), install (installation files), and log (log files).

[0032] 5) Launch File: An XML or Python script file used to configure and automatically start multiple ROS nodes and their parameters. It simplifies the startup process of complex systems containing multiple nodes.

[0033] 6) Template Engine: A software component used to combine template files (containing static text and dynamic placeholders) with a data model to generate the final text output (usually source code or configuration files). A common example is Jinja2, which supports logic such as variable substitution, conditional statements, and loops.

[0034] 7) Commit Hash: In version control systems like Git, this refers to a 40-digit hexadecimal string (or abbreviation) generated by algorithms such as SHA-1 that uniquely identifies a code commit. It serves as the "fingerprint" of the commit, used to precisely reference a specific code state in the repository history.

[0035] 8) Copier: An open-source project template generator based on Python and Jinja2. It reads user input parameters through question-and-answer interaction (CLI or configuration file) and automatically renders template files containing variable placeholders (such as {{pkg}}, {{node}}) into specific project files and directory structures.

[0036] 9) Repo: In version control systems (especially Git), a Repo is a storage unit used to store, manage, and track project files and historical changes. It contains complete project files, version history, branches, tags, and other metadata, and supports local operations and remote synchronization.

[0037] The software package synchronization scheme provided in this application embodiment utilizes templates to synchronize software packages for different scenario program projects. It obtains a target software package for a target scenario program project and a software package record file containing the template identifier and template version used to generate the target software package. Based on the template identifier, it determines the baseline template corresponding to the target software package. It compares the current version of the baseline template with the template version to check for differences. If differences exist, it synchronizes the differences to the target software package of the target scenario. This method can establish a precise mapping between multiple target software packages and software package versions in robot application development across multiple application scenarios, enabling batch updates of software packages. This application embodiment can be applied to the development of systems and applications based on template-based software architectures in various industrial, robotic, and autonomous vehicle fields. The embodiments of this application are described in detail below with reference to the accompanying drawings.

[0038] The first embodiment of this application provides a software package synchronization method, which will be described below in conjunction with... Figure 1 The implementation of each step of the method is described in detail, including steps S10-S30.

[0039] S10: Obtain a target software package and its software package record file for the target scenario program project. The software package record file records the template identifier and template version used when generating the target software package. The software package is generated based on a template version of the baseline template.

[0040] In some embodiments, the program project is a workspace directory for a scenario, including one or more software package directories, each of which includes a main function code directory, a resource folder directory, and configuration files. In this embodiment, a pre-set software package record file including a template identifier, template version, and template parameters is also included.

[0041] The template identifier is used to determine the source of the baseline template used to generate the software package, such as the path of the baseline template in the template repository. The template version is used to identify the specific state or commit point of the baseline template used when generating the software package, such as the hash value generated when the baseline template was committed to the template repository via git. The template parameters are a set of key-value pairs used for updating the content of the baseline template, including variable names and parameter values. For detailed implementation of this part, please refer to S30.

[0042] In some embodiments, the target scenario may refer to application scenarios of the same type of machine or robot for different tasks. These scenarios share the hardware foundation and core framework, but need to be adapted to different software packages, nodes, and parameter configurations. For example, the motion control of a motion robot in scenarios such as racing, obstacle finding, and cargo handling depends on different scenario configurations.

[0043] In some embodiments, the files in the software package include at least: a main function code directory containing node files for business logic; a manifest file defining package metadata and dependencies; a resource folder directory containing resource files required by the business logic; a configuration file used to deploy and start multiple nodes; the configuration file may include a package configuration file (defining package metadata, dependencies, compilation type, etc.), as well as a package installation script and a package installation configuration file; and a package log file for synchronous updates.

[0044] In some embodiments, the program project of the target scenario contains at least two software packages with dependencies; during synchronous updates, the synchronization order from the dependent package to the dependent package is determined based on the dependencies declared in the multiple software packages.

[0045] S20: Determine the baseline template corresponding to the target software package based on the template identifier.

[0046] In some embodiments, the benchmark template is generated in the following manner: Obtain the reference software package for the reference scenario; Replace the parameterized content in the reference software package file with template variables, and generate the baseline template; Each time the baseline template is modified, the modified baseline template is submitted to the template repository, and an independent template version is generated and stored together. Retrieve the current version of the baseline template from the template repository.

[0047] In some embodiments, the baseline template corresponding to the target software package includes at least one of the following directory or file templates: a main function code directory template, a resource file directory template, a package log file template, and a configuration file template. The configuration file may include a package configuration file (defining the package's metadata, dependencies, compilation type, etc.), and a package installation script and a package installation configuration file. The package installation script and configuration file template embed logic for dynamically generating multiple node startup commands based on a node list variable (such as {{ nodes}}). The package configuration file template can utilize the node list variable to dynamically configure the list of executable entry points for the software package (e.g., in setup.py) and related dependency declarations.

[0048] In some embodiments, the content that needs to be parameterized is replaced with placeholders. By converting the replaced package file into a template file (such as .jinja format), the identifiers are unified into formal template variables. For example, the package name mypkg1 (the content that needs to be parameterized) is replaced with the placeholder {{pkg}}.

[0049] In some embodiments, the base template may be formatted using a standard format defined by the template engine, such as .jinja, .j2, etc.

[0050] In some embodiments, the baseline template can also be obtained by integrating and modifying template files such as the basic template generated by the ROS official package creation command and the reference package of the reference scenario.

[0051] In some embodiments, modifying the benchmark template includes at least one of the following methods: modifying the content of existing node files in the benchmark template; deleting existing node files in the benchmark template; or adding node files to the benchmark template.

[0052] In some embodiments, the software package is created using a baseline template. A template engine tool is invoked, taking the baseline template and template parameters as input. The template variables in the baseline template are replaced with the specific values ​​provided by the template parameters, and the result is output. The template parameters can be a collection of key-value pairs containing template variables (key names) and template parameters (key values). The template parameters that need to be adjusted can be the directory name of the software package, the directory name of the main function code folder, or the filename of a resource file in the resource folder. For example, the directory name of the software package is placed in the baseline template using {{pkg}}, and the template parameters contain a key-value pair {“pkg”: “mypkg1”}. Using a template engine tool such as jinja2, the placeholder {{pkg}} in the baseline template is found based on the template variable (key name) “pkg”, and it is replaced with the template parameter (key value) “mypkg1”, thus completing the change of the software package's directory name.

[0053] In some embodiments, the package log file is automatically created when the package is generated using the package log file template and is stored together with the program project.

[0054] In some embodiments, a program project can be created based on a baseline template of a software package through an automated batch process, including: obtaining a list of baseline templates for multiple software packages required for the target scenario and a corresponding list of template parameters; wherein, the target software package list includes target software packages that need to be synchronized and their package record files; calling a templateization tool (such as the Copier tool) on each software package and its package record file baseline template in the baseline template list, using the corresponding template parameters as input, to perform a generation operation; and outputting the generated complete software package to a specified directory within the target program project workspace.

[0055] In some embodiments, directory-level synchronization of the program project is also included, specifically including: The target software package list is mapped and compared with the current baseline template list in the template repository; If a new software package benchmark template exists in the current benchmark template list, a new software package is created based on the new software package benchmark template and added to the program project; If a target software package no longer has a corresponding benchmark template in the current benchmark template list, then the target software package is removed from the program project.

[0056] In some embodiments, version management of the baseline template is achieved through a distributed version control system (such as git) and a multi-repository management tool (such as repo). For example, a unique hash value is generated by the git commit command as the version identifier, and all versions of the baseline template files are stored in a git repository (template repository). The repo tool manages the git repository containing multiple baseline templates through its manifest file. The repo manifest file (such as default.xml) defines the set of versions (current template list) that should be used for the current baseline template. The template version field (such as _commit) in the package log file records the hash value; the template identifier field (such as _src_path) records the repository path defined for the template in the repo manifest. By comparing the _commit value in the package log file with the hash value of the latest commit of the baseline template in the corresponding git repository in the template repository, it can be determined whether an update exists.

[0057] In some embodiments, when the repo tool is used to pull the baseline template, the metadata directory of the template repository (such as a git repository) is pulled to the top level of the target program project's workspace directory. This causes the template repository directory to no longer be a standard git repository, which in turn makes git commands that rely on relative paths to locate the .git directory ineffective (such as the Copier tool which locates the template repository via a relative path to perform updates). Therefore, before calling a templateization tool (such as the Copier tool) to generate update content, the file path or Uniform Resource Identifier of the package record file, the baseline template, or the template repository is absoluteized, that is, it is converted into an absolute path or a complete URI format (such as file: / / / absolute / path / to / template.git).

[0058] S30: Compare the current version of the benchmark template with the template version to check for differences; synchronize the differences between the current version of the benchmark template and the target software package to the target software package of the target scene; wherein, the differences are the parts of the current version of the benchmark template that are inconsistent with the content of the target software package.

[0059] In some embodiments, the software package log file further includes version parameters, and synchronizing the differences between the current version of the baseline template and the target software package to the target software package of the target scenario includes: The portion of the difference content involving template variables is replaced with the corresponding template parameters recorded in the package log file to generate updated content adapted to the target package; wherein, the template variables are the parameterized content in the base template that needs to be replaced; The updated content will be synchronized to the target software package in the target scenario.

[0060] In some embodiments, the differences may be directories, files, or (code) content in files added or deleted by the software package.

[0061] For example, consider a baseline template, currently version 2.0, and a target software package created based on version 1.0 of the baseline template. In the baseline version 2.0, the node file contains the line: "Hi from {{pkg}}." This line represents the difference between the current version of the baseline template and the target software package. {{pkg}} is a template variable, representing the parameterized content to be replaced. The one-key value pair {"pkg": "mypkg1"} is retrieved from the target software package's package record file and replaced, resulting in the code "Hi from mypkg1.", which is the updated content. This line is then added to the target software package's node file to complete the synchronization update.

[0062] For example, consider a baseline template, currently at version 2.0, and a target software package created based on version 1.0 of that baseline. In version 2.0 of the baseline, a new resource file, {{pkg}}resource, has been added to the resource file directory. The key-value pair {"pkg": "mypkg1"} is replaced to obtain the file mypkg1resource. This file is then added to the resource file directory of the target software package to complete the synchronization update.

[0063] In some embodiments, synchronizing the updated content to the target software package of the target scenario can be automatically accomplished through the update command of a template tool (such as Copier). This command reads the package record file in the target software package, locates the corresponding baseline template and its version, performs difference comparison and parameter replacement, and then automatically merges the generated, directly applicable code and configuration patches (update content) into the corresponding file of the target software package, thereby completing the synchronization.

[0064] In some embodiments, the content described in steps S10-S40 can be integrated into a command-line (CLI) tool, which can be synchronized via terminal invocation.

[0065] The second embodiment of this application provides a software package synchronization method. The following will refer to... Figure 2a The flowchart shown illustrates that the method provided in this second embodiment includes the following steps S200-S230.

[0066] ROS2 (Robot Operating System 2) is an open-source framework for robot application development. The development and application of existing ROS2 applications mainly occur on Ubuntu machines and include the following steps: 1) Create a workspace (program project) by running the command mkdir -p <workspace> / src.

[0067] 2) In the src directory, create a package by running the command ros2 pkg create or copy an existing package.

[0068] 3) Modify the package code using an editor.

[0069] 4) In the <workspace> directory, compile one or more packages by running the command colcon build.

[0070] 5) Run the package by running the command ros2 run <package> <node> or the command ros2 launch <package> <launch file>.

[0071] As can be seen from the above process, for an actual robot application scenario that may contain multiple packages and nodes, if you want to migrate the workspace (program project) of an existing scenario to another scenario, you need to modify the personalized parameters for that scenario, which is a cumbersome process. Therefore, the embodiments of this application extract an existing robot reference scenario as a benchmark template through the following steps, so that a program project in a new application scenario can be quickly created. At the same time, version control and update iteration of the program project in the new application scenario can be achieved through the benchmark template, making scenario-based development based on ROSI continuous.

[0072] S200: Generate a package benchmark template based on the reference scenario.

[0073] As Figure 2b shown, the scenario template of the package contains multiple package benchmark templates modified based on the reference scenario packages.

[0074] The package modification is completed using the Copier tool. Specifically, it includes steps S201 - S204.

[0075] S201: Create a reference scenario scene and packages mypkg1 and mypkg2 using the following command, where each package has a node.

[0076]

[0077] The directory structure for the reference scenario is shown below, including a `src` folder containing two package directories (`mypkg1`, `mypkg2`). Taking the `mypkg1` package as an example, the package directory contains a main function code folder `mypkg1` and a resource folder `resource`. The main function code folder includes the node file `mynode1.py`. The package directory also includes the package configuration file `package.xml` (defining the package's metadata, dependencies, compilation type, etc.), as well as the package installation script and package installation configuration files `setup.py` and `setup.cfg`.

[0078]

[0079] S202: Modify the mypkg1 and mypkg2 software packages in the above reference scenario into a software package baseline template.

[0080] like Figure 2c As shown, taking the mypkg1 package as an example, the package directory name, the directory name of the main function code folder, and the file names of the resource files in the resource folder are parameters that need to be adjusted. Replace them with the variable {{pkg}}.

[0081] The functional node code file mynode1.py, the package configuration file package.xml, and the scripts and configuration files setup.py and setup.cfg used for package installation need to be transformed into template file format .jinjia.

[0082] Specifically, by parameterizing mypkg1 in mynode1.py and replacing it with the variable {{pkg}}, it is transformed into the {{node}}.py.jinja template file:

[0083] Similarly, replace `mypkg1` in `package.xml` with the variable `{{pkg}}`, and modify it into a `package.xml.jinja` file:

[0084] Also, replace mypkg1 in setup.cfg with the variable {{pkg}}, and rename it to setup.cfg.jinja file:

[0085] In setup.py, you need to replace mypkg1 with the variable {{pkg}}, and use the configuration to reference the list of nodes in this package via {%for node in nodes%}, and generate the list of nodes using {{node}} = {{pkg}}.{{node}}:main, to ensure the package runs correctly.

[0086] In addition, a launch file needs to be generated for running the software package, as well as a package log file containing template version information.

[0087] Create a file named launch.py.jinjia (which can be stored in the launch folder under the package directory), and use {%for node in nodes%} to reference the list of nodes in this package to support launching multiple nodes at the same time.

[0088]

[0089] Create a file named {{_copier_conf.answers.file}}.jinja. This file will be used to generate a package using the Copier tool, and will also create a file named .copier-answers.yml. The content of the {{_copier_conf.answers.file}}.jinja file is as follows:

[0090] The `{{ _copier_answers|to_nice_yaml -}}` directive generates the contents of the `_copier_answers` dictionary, which is automatically retrieved by the Copier tool, and converts it to .yml format. The `_copier_answers` dictionary includes the source path `_src_path` of the template file used to generate the package and the hash value `_commit` generated during git commits.

[0091] S203: Save the modified mypkg1 and mypkg2 package directories as template1 and template2 base templates, and submit them to the same program project group in the git repository for unified management.

[0092] S204: Create a template_manifest project under this project group, which is the manifest project. This project will manage multiple base package template repositories through default.xml. The default.xml file is shown below, containing the name and path of the base template.

[0093]

[0094] At this point, the package base template and its Git repository have been created.

[0095] S210: Create a new scenario based on multiple software package baseline templates.

[0096] Use the repo tool to retrieve the program project directory (scene template) containing the template1 and template2 baseline templates:

[0097] The resulting scenario template structure is as follows, omitting the .git and .repo directories. The directory structure of the baseline template is as described above. Figure 2c As shown.

[0098]

[0099] Create a file named copier_run.py and run it to invoke the copier tool to create a new scene. The specific code for copier_run.py is shown below. The file will first check if a new package with the same name as the base template contained in the scene template exists in the new scene. If it does not exist, it will create a new package based on the base template.

[0100] Specifically, in the new scenario, copy the baseline template, and then replace the variables in the baseline template, such as pkg, with the corresponding key-value pairs (template parameters) of pkg, mypkg1, by defining (or reading from the package record file) key-value pairs of template parameters in the copier_run.py folder.

[0101]

[0102] In this embodiment, the `repo` tool collects the `.git` directories of each sub-project (base template) in the `git` repository into the `.repo` directory, causing `git` commands using relative paths to be unsupported. Therefore, the `repo` source code can be modified to change some relative paths to absolute paths to ensure the correct operation of the `copier_run.py` file. For example, the `clone` function in `copier / _vcs.py` can be modified as follows:

[0103] In addition, modify the `_answers_to_remember` function in `copier / _main.py` as follows:

[0104] After running the copier_run.py file, the directory structure generated in the new scene is as follows. It can be noted that the directory structure of the generated new scene is basically the same as that of the original reference scene, with the addition of a launch folder and a copier-answers.yml file.

[0105]

[0106] The `copier-answers.yml` file, as described above, contains the path and version of the base template. The following shows the git commit hash of `template1` (i.e., the template version described in the first embodiment) and the template path (i.e., the template identifier described in the first embodiment). This hash value is used to add the base template version, i.e., the template identifier, to the new software package.

[0107]

[0108] S220: Modify the structure of the scene template and the base template of the software package to obtain a new scene template.

[0109] Add a node mynode4 to the package base template template1, and create a template file for the code file of that node, as shown below.

[0110]

[0111] At the same time, add a new package baseline template, template3, to the scene templates.

[0112] Submit the above changes to the Git repository, and modify the default.xml file under the new scenario template_manifest project, adding the name and address of the new package base template template3 to complete the template repository update. The new default.xml file is shown below:

[0113] S230: Synchronize changes to the baseline template to the program project in the target scenario.

[0114] Adjust the `copier_run.py` file, adding the `template3` baseline template and the newly added `mynode4` node from the `template1` baseline template to the list of baseline templates that need updating. Specifically:

[0115] Run the copier_run.py file in the target scenario (i.e. the newly created scenario) to perform a synchronous update.

[0116] When a baseline template is submitted, each baseline template has a hash value as the template version. When the copier_run.py file is run, the Copier tool will obtain this hash value and compare it with the hash value recorded in the copier-answers.yml file of the target scenario. If they are inconsistent, Copier will obtain the differences between the target package and the baseline template, generate a patch, and synchronize it to the package of the target scenario.

[0117] Finally, the synchronized target scene directory structure is shown below. It can be seen that the newly added template1 base template's mynode4 node and the content of the template3 base template have been successfully synchronized to the target scene.

[0118]

[0119] The third embodiment of this application provides a method for synchronizing program projects. The program project contains at least two target software packages, and at least two target software packages are updated through batch processing. The following will refer to... Figure 3 The method provided in this third embodiment, illustrated by the flowchart, includes the following steps S300-S310: S300: Obtain the list of target software packages that need to be synchronized in the program project; wherein, the list of target software packages includes the target software packages that need to be synchronized and the corresponding software package record files.

[0120] S310: Traverse the list, and for each target software package and its corresponding software package record file in the list, execute the software package synchronization method described in the first embodiment in sequence to complete the synchronization update of the program project.

[0121] In some embodiments, the method further includes structural synchronization of the program project, specifically including: The target package list is mapped and compared with the current template list obtained from the template repository; If the template version of a target software package is inconsistent with the current version of the corresponding software package baseline template in the template repository, the software package synchronization method described in claim 1 shall be executed to update it; If a new software package baseline template exists in the current template list, a new software package is created based on the new software package baseline template and added to the program project; If a target software package no longer has a corresponding baseline template in the current template list, then the target software package is removed from the program project.

[0122] The fourth embodiment of this application provides a software package synchronization device, which can be used to implement the software package synchronization method in the above embodiments, such as... Figure 4 As shown, the software package synchronization device includes: The scene information acquisition module is used to acquire a target software package and its corresponding software package record file of the target scene program project. The software package record file records the template identifier and template version used when generating the target software package. The software package is generated based on a template version of a baseline template. Specifically, the scene information acquisition module can be used to implement step S10 in the first embodiment and its optional embodiments.

[0123] The template determination module is used to determine the baseline template corresponding to the target software package based on the template identifier; specifically, the template determination module can be used to implement step S20 in the first embodiment and its optional embodiments.

[0124] The software package update module is used to compare the current version of the baseline template that needs to be updated with the template version and check whether there are any differences. If there are, the software package update module will be synchronized to the target software package of the target scene based on the differences. Specifically, the software package update module can be used to implement step S30 in the first embodiment and its optional embodiments.

[0125] Figure 5 This is a schematic structural diagram of a computing device 900 provided in an embodiment of this application. This computing device can execute various optional embodiments of the methods described above. The computing device can be a terminal, or a chip or chip system within the terminal. Figure 5 As shown, the computing device 900 includes: a processor 910, a memory 920, and a communication interface 930.

[0126] It should be understood that Figure 5 The communication interface 930 in the computing device 900 shown can be used to communicate with other devices, and may specifically include one or more transceiver circuits or interface circuits.

[0127] The processor 910 can be connected to the memory 920. The memory 920 can be used to store the program code and data. Therefore, the memory 920 can be a storage unit inside the processor 910, an external storage unit independent of the processor 910, or a component that includes both the storage unit inside the processor 910 and the external storage unit independent of the processor 910.

[0128] Optionally, the computing device 900 may also include a bus. The memory 920 and communication interface 930 can be connected to the processor 910 via the bus. The bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The symbol is represented by a line without an arrow, but this does not mean that there is only one bus or one type of bus.

[0129] It should be understood that in the embodiments of this application, the processor 910 may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. Alternatively, the processor 910 may employ one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0130] The memory 920 may include read-only memory and random access memory, and provides instructions and data to the processor 910. A portion of the processor 910 may also include non-volatile random access memory. For example, the processor 910 may also store device type information.

[0131] When the computing device 900 is running, the processor 910 executes computer execution instructions stored in the memory 920 to perform any of the operational steps of the above method and any of the optional embodiments thereof.

[0132] It should be understood that the computing device 900 according to the embodiments of this application can correspond to the corresponding subject in executing the methods according to the various embodiments of this application, and the above and other operations and / or functions of each module in the computing device 900 are respectively for implementing the corresponding processes of the methods of this embodiment. For the sake of brevity, they will not be described in detail here.

[0133] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0134] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0135] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0136] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0137] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0138] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0139] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, performs the above-described method, which includes at least one of the schemes described in the above embodiments.

[0140] The computer storage medium in this application embodiment can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0141] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0142] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0143] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0144] Furthermore, the terms "first, second, third, etc." or similar terms such as module A, module B, and module C used in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of objects. It is understood that, where permissible, a specific order or sequence may be interchanged so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0145] In the above description, the labels of the steps involved, such as S110, S120, etc., do not mean that the steps will necessarily be executed. The order of the steps can be interchanged or executed simultaneously if permitted.

[0146] The term "comprising" as used in the specification and claims should not be construed as limiting itself to what follows; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the mentioned feature, integral, step, or component, but does not exclude the presence or addition of one or more other features, integrals, steps, or components, or groups thereof. Thus, the statement "device comprising means A and B" should not be limited to a device consisting solely of components A and B.

[0147] The terms "an embodiment" or "an embodiment" as used in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in at least one embodiment of this application. Therefore, the terms "in one embodiment" or "in an embodiment" appearing throughout this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. Furthermore, in one or more embodiments, the particular features, structures, or characteristics can be combined in any suitable manner, as will be apparent to those skilled in the art from this disclosure.

[0148] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, all of which fall within the scope of protection of this application.

Claims

1. A software package synchronization method, characterized in that, The method for synchronizing software packages from different scenario program projects using templates includes: Obtain a target software package and its package record file for the target scenario program project. The package record file records the template identifier and template version used when generating the target software package. The software package is generated based on a template version of a baseline template. Based on the template identifier, determine the baseline template corresponding to the target software package; Compare the current version of the benchmark template with the template version to check for differences; if differences exist, synchronize the differences between the current version of the benchmark template and the target software package to the target software package of the target scene; wherein, the differences are the parts of the current version of the benchmark template that are inconsistent with the content of the target software package.

2. The method according to claim 1, characterized in that, The baseline template is generated in the following way: Obtain the reference software package for the reference scenario; Replace the parameterized content in the reference software package file with template variables, and generate the baseline template; Each time the baseline template is modified, the modified baseline template is submitted to the template repository, and an independent template version is generated and stored together. Retrieve the current version of the baseline template from the template repository.

3. The method according to claim 2, characterized in that, The software package log file also includes template parameters, which synchronize the differences between the current version of the baseline template and the target software package to the target software package for the target scenario, including: The portion of the difference content involving template variables is replaced with the corresponding template parameters recorded in the package log file to generate updated content adapted to the target package; wherein, the template variables are the parameterized content in the base template that needs to be replaced; The updated content will be synchronized to the target software package in the target scenario.

4. The method according to claim 3, characterized in that, The target software package includes at least one of the following directories or files: main function code directory, resource folder directory, software package log file, and configuration file; The baseline template corresponding to the target software package includes at least one of the following directory or file templates: main function code directory template, resource file directory template, software package record file template, and configuration file template.

5. The method according to claim 4, characterized in that, The file path of the baseline template or the template repository is absolute; During software package synchronization, the baseline template is obtained either by using an absolute file path or from the template repository with an absolute file path.

6. A method for synchronizing program projects, characterized in that, The program project contains at least two target software packages, and the method for updating at least two target software packages via batch processing includes: Obtain the list of target software packages that need to be synchronized in the program project; wherein, the list of target software packages includes the target software packages that need to be synchronized and their package record files; The list is traversed, and for each target software package and its package record file in the list, the software package synchronization method described in claim 1 is executed sequentially to complete the synchronization update of the program project.

7. The method according to claim 6, characterized in that, It also includes directory-level synchronization of the program project, specifically including: The target software package list is mapped and compared with the current baseline template list obtained from the template repository; If a new software package benchmark template exists in the current benchmark template list, a new software package is created based on the new software package benchmark template and added to the program project; If a target software package no longer has a corresponding benchmark template in the current benchmark template list, then the target software package is removed from the program project.

8. A software package synchronization device, characterized in that, include: The scene information acquisition module is used to acquire a target software package and its software package record file of the target scene program project. The software package record file records the template identifier and template version used when generating the target software package. The software package is generated based on a template version of a baseline template. The template determination module is used to determine the baseline template corresponding to the target software package based on the template identifier; The software package update module is used to compare the current version of the benchmark template with the template version to check for differences; if differences exist, the differences between the current version of the benchmark template and the target software package are synchronized to the target software package of the target scenario; wherein, the differences are the parts of the current version of the benchmark template that are inconsistent with the content of the target software package.

9. A computing device, characterized in that, include: processor, and A memory storing program instructions that, when executed by the processor, cause the processor to perform the software package synchronization method according to any one of claims 1 to 5, and the program item synchronization method according to any one of claims 6 to 7.

10. A computer-readable storage medium, characterized in that, It stores program instructions that, when executed by a computer, cause the computer to perform the software package synchronization method according to any one of claims 1 to 5, and the program item synchronization method according to any one of claims 6 to 7.

Images