# packages

pkgId: e799521f68a0529125a909f0bc7952cd57d0339f43a43e1cf47b9bae23727c0b
name: python-gdsfactory-help
arch: noarch
version: 8.26.0
epoch: 0
release: 1
summary: Development documents and examples for gdsfactory
url: https://pypi.org/project/gdsfactory/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gdsfactory-8.26.0-1.src.rpm
location_href: Packages/python-gdsfactory-help-8.26.0-1.noarch.rpm
checksum_type: sha256
description:
  "I've relied on **GDSFactory** for several tapeouts over the years. It's the only tool I've found that gives me the flexibility and scalability I need for a variety of projects."


pkgId: fbac4d2e4cf7c3324f70c46462026ee5cfe900083f7949edc04876b48d45e55c
name: python-gebpy-help
arch: noarch
version: 1.0.2
epoch: 0
release: 1
summary: Development documents and examples for gebpy
url: https://github.com/MABeeskow/GebPy
rpm_license: LGPL-3.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gebpy-1.0.2-1.src.rpm
location_href: Packages/python-gebpy-help-1.0.2-1.noarch.rpm
checksum_type: sha256
description:
  [![Python 3.7](https://img.shields.io/badge/python-3.7-blue.svg)](https://www.python.org/downloads/release/python-370/) [![License: LGPL v3](https://img.shields.io/badge/License-LGPL%20v3-blue.svg)](https://www.gnu.org/licenses/lgpl-3.0)

  <a href="https://github.com/MABeeskow/GebPy">
    <img src="https://raw.githubusercontent.com/MABeeskow/GebPy/master/documents/readme_images/readme_header.png" width="67%">
  </a>

  developed by Maximilian Alexander Beeskow

  GebPy is an open-source, Python-based tool for the synthetic generation of geological data with focus on minerals, rocks and stratigraphy. The main assumption of GepPy is that all rock properties are determined by the mineral assemblage besides structural features. GebPy can be used for educational purposes, for example by the generation of mineralogical data that could be then further investigated in specific diagrams or in well log analysis courses after creating different stratigraphic sequences.\
  GebPy is a one-man project and can still contain some technical bugs or some wrong assumptions, but it is driven by a huge motivation and has the goal to improve the knowledge and understanding of different geological aspects that are (actually) focused on mineralogy, rocks and stratigraphy.



  Actually, GebPy can only be installed by cloning this repository. An alternative solution will be found in the future.



  Coming soon ...



  Coming soon ...



  Coming soon ...



  Coming soon ...



  Coming soon ...



  Coming soon ...


pkgId: 162e74720308ad34355fc36731af4fca1059d03d101e247e0403ed07f84ed676
name: python-gemini-gradio-help
arch: noarch
version: 0.0.3
epoch: 0
release: 1
summary: Development documents and examples for gemini-gradio
url: https://pypi.org/project/gemini-gradio/
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gemini-gradio-0.0.3-1.src.rpm
location_href: Packages/python-gemini-gradio-help-0.0.3-1.noarch.rpm
checksum_type: sha256
description:
  Note: if you are getting an authentication error, then the Gemini API Client is not able to get the API token from the environment variable. You can set it in your Python session like this:
  ```python
  import os
  os.environ["GEMINI_API_KEY"] = ...
  ```


pkgId: b19daccbbed1adf9a9364474635bc0bf48142b6322b718ca2785c33e6c4841cf
name: python-gencove-help
arch: noarch
version: 2.24.3
epoch: 0
release: 1
summary: Development documents and examples for gencove
url: https://docs.gencove.com
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gencove-2.24.3-1.src.rpm
location_href: Packages/python-gencove-help-2.24.3-1.noarch.rpm
checksum_type: sha256
description:
  [![PyPI Latest Release](https://img.shields.io/pypi/v/gencove.svg)](https://pypi.org/project/gencove/)
  [![License](https://img.shields.io/pypi/l/gencove.svg)](https://github.com/gncv/gencove-cli/blob/master/LICENSE)



  Gencove is a high-throughput, cost-effective platform for genome sequencing and analysis, enabling a wide array of genomics applications across industries. Furthermore, it is the only enterprise analytics platform for low-pass whole genome sequencing (lpWGS).


  The Gencove command-line interface (CLI) can be used to easily access the Gencove platform.



  It is most often used for:
  * [Uploading FASTQ files](https://docs.gencove.com/base/analysis/fastq-files/uploading-using-the-cli/) for analysis
  * [Downloading analysis results](https://docs.gencove.com/base/analysis/samples/downloading-deliverables/) which include the following:
    * Sequence (`.fastq.gz`)
    * Alignment (`.bam`, `.bai`)
    * Imputation (`.vcf.gz`, `.vcf.gz.tbi`, `.vcf.gz.csi`)
  * [Assigning metadata](https://docs.gencove.com/base/analysis/samples/sample-metadata-and-files/#assigning-sample-metadata) to Gencove samples

  Before filing a bug report, please refer to the following [link](https://docs.gencove.com/general/support/#filing-a-bug-report-for-the-cli). Bugs should be reported [here](https://resources.gencove.com/hc/en-us/requests/new).


  ```

  pip install gencove


  pip install -U gencove
  ```



  Online documentation (with examples) is available at [docs.gencove.com](https://docs.gencove.com/base/getting-started/)

  API reference for publicly available endpoints: [API Reference](https://api.gencove.com/api/v2/docs/)

  Comprehensive CLI Documentation available: [CLI Reference](https://docs.gencove.com/base/cli-reference/)


pkgId: 925e7ea7897540a139432b6740fe5ff58b841d23abcd76923ffa3e4afb63f8c5
name: python-gendia-help
arch: noarch
version: 1.1.0
epoch: 0
release: 1
summary: Development documents and examples for gendia
url: https://github.com/Silicon27/gendia
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gendia-1.1.0-1.src.rpm
location_href: Packages/python-gendia-help-1.1.0-1.noarch.rpm
checksum_type: sha256
description:
  Imagine this: you are on Discord and is request help from someone about a project you are working on. You want to show the structure of your project directory to the person. You can't just send a screenshot of the directory because it's too big and the person won't be able to see the whole structure. You can't just send a text file with the structure because it's too boring and the person won't be able to understand it easily. What do you do? You use `gendia`!
  Heres an example of a tree structured diagram generated by `gendia`:
  ```
  project
  ├── src
  │   ├── main.py
  │   ├── utils
  │   │   ├── __init__.py
  │   │   ├── helper.py
  │   │   └──  helper2.py
  │   ├── tests
  │   │   ├── __init__.py
  │   │   ├── test_main.py
  │   │   └──  test_helper.py
  │   └── README.md
  ├── LICENSE
  └── .gitignore
  ```
  Not just that, it is color coded! The directories are in blue, and different file types are in different colors. This makes it easier to understand the structure of the directory.

  To add `gendia` to your project, run:
  ```bash
  pip install gendia
  ```
  This should install `gendia` to your project. You can now use it to generate tree structured diagrams for your directories.

  To use `gendia`, run:
  ```bash
  gendia path/to/directory
  ```
  This should generate a tree structured diagram for the directory you specified. You can also specify the output file by using the `-o` flag:
  ```bash
  gendia path/to/directory -o output.txt
  ```
  This should generate a tree structured diagram for the directory you specified and save it to `output.txt`.
  `--hidden` flag can be used to show hidden files and directories:
  ```bash
  gendia path/to/directory --hidden
  ```


pkgId: 6c0561bf90a2d3972949c5352732a6a671f0a7ca14e0c64f2c871f62f57baefb
name: python-geneplexus-help
arch: noarch
version: 1.0.1
epoch: 0
release: 1
summary: Development documents and examples for geneplexus
url: https://github.com/krishnanlab/PyGenePlexus
rpm_license: BSD 3-Clause License
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-geneplexus-1.0.1-1.src.rpm
location_href: Packages/python-geneplexus-help-1.0.1-1.noarch.rpm
checksum_type: sha256
description:
  [![Tests](https://github.com/krishnanlab/PyGenePlexus/actions/workflows/tests.yml/badge.svg)](https://github.com/krishnanlab/PyGenePlexus/actions/workflows/tests.yml)
  [![Documentation Status](https://readthedocs.org/projects/pygeneplexus/badge/?version=main)](https://pygeneplexus.readthedocs.io/en/main/?badge=main)
  [![PyPI](https://img.shields.io/pypi/v/geneplexus)](https://pypi.org/project/geneplexus/)
  ![PyPI - Python Version](https://img.shields.io/pypi/pyversions/geneplexus)
  [![License](https://img.shields.io/badge/License-BSD_3--Clause-blue.svg)](https://opensource.org/licenses/BSD-3-Clause)
  [![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)



  A Python package of the GenePlexus analysis pipeline.

  * The [GenePlexus paper](https://academic.oup.com/bioinformatics/article/36/11/3457/5780279)
  * The [repository](https://github.com/krishnanlab/GenePlexus) for reproducing the experiments
  * The [webserver](https://www.geneplexus.net/)
  * [Documentation](https://pygeneplexus.readthedocs.io)
  * Data [![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.6383205.svg)](https://doi.org/10.5281/zenodo.6383205)





  Install the ``GenePlexus`` package via ``pip``.

  ```bash
  pip install geneplexus
  ```





  See `example/example_run.py` for example usage of the API.



  ```bash
  geneplexus --input_file example/input_genes.txt --output_dir example_result
  ```

  Full CLI options (check out with ``geneplexus --help``)

  ```txt
  Run the GenePlexus pipline on a input gene list.

  optional arguments:
    -h, --help            show this help message and exit
    -i , --input_file     Input gene list (.txt) file (one gene per line). (default: None)
    -d , --gene_list_delimiter
                          Delimiter used in the gene list. Use 'newline' if the genes are separated
                          by new line, and use 'tab' if the genes are seperate by tabs. Other
                          generic separator are also supported, e.g. ', '. (default: newline)
    -n , --network        Network to use. {format_choices(config.ALL_NETWORKS)} (default: STRING)
    -f , --feature        Types of feature to use. The choices are: {Adjacency, Embedding,
                          Influence} (default: Embedding)
    -g , --gsc            Geneset collection used to generate negatives and the modelsimilarities.
                          The choices are: {GO, DisGeNet} (default: GO)
    -s , --small_edgelist_num_nodes
                          Number of nodes in the small edgelist. (default: 50)
    -dd , --data_dir      Directory in which the data are stored, if set to None, then use the
                          default data directory ~/.data/geneplexus (default: None)
    -od , --output_dir    Output directory with respect to the repo root directory. (default:
                          result/)
    -l , --log_level      Logging level. The choices are: {CRITICAL, ERROR, WARNING, INFO, DEBUG}
                          (default: INFO)
    -q, --quiet           Suppress log messages (same as setting log_level to CRITICAL). (default:
                          False)
    -z, --zip-output      If set, then compress the output directory into a Zip file. (default:
                          False)
    --clear-data          Clear data directory and exit. (default: False)
    --overwrite           Overwrite existing result directory if set. (default: False)
    --skip-mdl-sim        Skip model similarity computation. This computation is not yet available
                          when using custom networks due to the lack of pretrained models for
                          comparison. (default: False)
  ```





  Install the PyGenePlexus package in editable mode with dev dependencies

  ```bash
  pip install -e ."[dev]"
  ```



  Run the default test suite

  ```bash
  pytest test/
  ```

  By default, test data will be cached. Thus, after the first test run, data redownload will not be tested. To force redownload, specify the ``--cache-clear`` option

  ```bash
  pytest test/ --cache-clear
  ```



  1. Install doc dependencies ``pip install -r docs/requirements.txt``
  2. Build
  ```bash
  cd docs
  make html
  ```
  3. Open doc ``open build/html/index.html``


pkgId: 80396662d337b125e0b435165b73bdb80d41836f33364be1b22e83977875fbc4
name: python-general-class-balancer-help
arch: noarch
version: 0.0.1
epoch: 0
release: 1
summary: Development documents and examples for general-class-balancer
url: https://github.com/mleming/general_class_balancer
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-general-class-balancer-0.0.1-1.src.rpm
location_href: Packages/python-general-class-balancer-help-0.0.1-1.noarch.rpm
checksum_type: sha256
description:
  This program finds a subset of your dataset with balanced confounding factors (also known as "data matching"), though it can work with any combination of categorical and continuous variables.

  Given a labeled dataset with any number of classes and a number of confounding factors for each datapoint, this matches data in each class to one another, such that the distributions of each confounding factor are the same in each class. This may be used to sample a training set on which a given deep learning model will not take confounding factors into account during its classification.

  A version of this method was originally introduced in https://arxiv.org/abs/2002.07874 to ensure that deep learning classifications of sex based on brain activity did not take into account head motion or intracranial volume, both of which are statistically different between sexes and which affect measurements of brain activity, but which we did not want the machine learning model to consider. A more detailed explanation of the method may be found in that paper. Below is a pictural description of the algorithm (assuming plim = 0.10)

  ![alt text](description.png "A description of the general class balancer algorithm")

  Everything in the presented code uses numpy arrays. The code, as well as a script that simulates data from random variables, is given. Simply run


  ```
  python random_example_test.py
  ```


pkgId: c2c72758e0c57e0904b1d6f36643bedcb8d7e50c626d8e2b3f43b72da47c3cf0
name: python-general-superstaq-help
arch: noarch
version: 0.5.33
epoch: 0
release: 1
summary: Development documents and examples for general-superstaq
url: https://pypi.org/project/general-superstaq/
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-general-superstaq-0.5.33-1.src.rpm
location_href: Packages/python-general-superstaq-help-0.5.33-1.noarch.rpm
checksum_type: sha256
description:
  This package contains code that is common across our clients ([cirq-superstaq](https://github.com/Infleqtion/client-superstaq#-cirq-superstaq-) and [qiskit-superstaq](https://github.com/Infleqtion/client-superstaq#-qiskit-superstaq-)) and [Supermarq](https://github.com/Infleqtion/client-superstaq#-supermarq-).


pkgId: 35c3c452b61f4588ec294a7a8d677368ef073d0d5234ee33e2e8977832444915
name: python-generate-gitignore-help
arch: noarch
version: 0.1.0
epoch: 0
release: 1
summary: Development documents and examples for generate-gitignore
url: https://github.com/kristiankunc/generate-gitignore
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-generate-gitignore-0.1.0-1.src.rpm
location_href: Packages/python-generate-gitignore-help-0.1.0-1.noarch.rpm
checksum_type: sha256
description:
  A simple Python script to generate a .gitignore file for your project using the templates from [github.com/github/gitignore](https://github.com/github/gitignore)




  Templates are taken from the [github.com/github/gitignore](https://github.com/github/gitignore) repository and are updated every 24 hours.

  The parsed list of templates can be found in the [templates.json](templates.json) file. This file is used by the script to generate the list of available templates.

  I am not a maintainer of the gitignore source repository, so if you wish to have a template added, please open an issue or a pull request on the source repository as I do not maintain any custom templates.



  > [!WARNING]
  > Applying a template will overwrite any existing .gitignore file in the current directory, you will be prompted to confirm before proceeding.

  Once installed, you can run the script with the following command:

  ```bash
  generate-gitignore
  ```



  You can list all available templates with the list command:

  ```bash
  generate-gitignore list
  ```



  You can search for a template with the search command, it will launch an interactive search in the terminal allowing you to search by name and apply the selected template:

  ```bash
  generate-gitignore search
  ```



  If you want to apply a template directly, you can use the apply command followed by the template name:

  ```bash
  generate-gitignore apply python
  ```



  Contributions are welcome, please open an issue or a pull request if you wish to contribute. Make sure to follow the [Contribution Guidelines](CONTRIBUTING.md) before submitting a pull request.


pkgId: c697dbbf662d559449b6323bb7627c1e49024b454f5553a7b0e497f46262f025
name: python-generic-preserver-help
arch: noarch
version: 0.1.3
epoch: 0
release: 1
summary: Development documents and examples for generic-preserver
url: https://pypi.org/project/generic-preserver/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-generic-preserver-0.1.3-1.src.rpm
location_href: Packages/python-generic-preserver-help-0.1.3-1.noarch.rpm
checksum_type: sha256
description:
  Thank you for using `generic-preserver`! If you find this package helpful, consider giving it a star on GitHub.


pkgId: 884bffd239ff3e34c3f6e9ab846549c43e27e5bc66f2f0573c76ecd7689420c0
name: python-geneticanalyzer-help
arch: noarch
version: 1.1.3
epoch: 0
release: 1
summary: Development documents and examples for geneticanalyzer
url: https://github.com/MemerGamer/GeneticAnalyzer
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-geneticanalyzer-1.1.3-1.src.rpm
location_href: Packages/python-geneticanalyzer-help-1.1.3-1.noarch.rpm
checksum_type: sha256
description:
  - **Track Lineage**: Log individuals, parental relationships, and mutations across generations.
  - **Visualize Family Tree**: Generate a graph of the population's lineage to trace genetic evolution.
  - **Highlight Best Individuals**: Mark the highest-performing individual and trace their ancestry.


pkgId: 21cf3225131191dc41590f86ff42b35e530ec3a6c3239907567feec8e0ba2ae3
name: python-genieutils-py-help
arch: noarch
version: 0.0.5
epoch: 0
release: 1
summary: Development documents and examples for genieutils-py
url: https://github.com/SiegeEngineers/genieutils-py
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-genieutils-py-0.0.5-1.src.rpm
location_href: Packages/python-genieutils-py-help-0.0.5-1.noarch.rpm
checksum_type: sha256
description:
  Python implementation of [genieutils](https://github.com/Tapsa/genieutils).

  This library can be used to read and write `empires2_x2_p1.dat` files for Age of Empires II Definitive Edition.




  Currently, only the recent versions used in Age of Empires II Definitive Edition are supported
  (`GV_C20` and above, corresponding to FileVersion 7.7 and above).




  ```shell
  pip install genieutils-py
  ```





  The package comes with a handy command line tool that does that for you.

  ```shell
  dat-to-json path/to/empires2_x2_p1.dat
  ```




  ```python
  from genieutils.datfile import DatFile

  data = DatFile.parse('path/to/empires2_x2_p1.dat')
  data.techs[22].resource_costs[0].amount = 69
  data.save('path/to/modded/empires2_x2_p1.dat')
  ```



  ```python
  from genieutils.datfile import DatFile

  data = DatFile.parse('path/to/empires2_x2_p1.dat')
  for civ in data.civs:
      civ.units[434].bird.tasks.pop()
  data.save('path/to/modded/empires2_x2_p1.dat')
  ```



  **Before running tests, you need to add sample `empires2_x2_p1.dat` files into the `tests/testdata` subfolder.**

  1. Create a virtual environment
     `python3 -m venv venv`
  2. Activate the virtual environment
     `source venv/bin/activate`
  3. Install the dev dependencies
     `pip install -r requirements-dev.txt`
  4. Install the local checkout of genieutils-py in editable mode
     `pip install -e .`
  5. Run the test script
     `./test`




  [HSZemi](https://github.com/hszemi) - Original Author


pkgId: 2d069401d0aca1b45535164f4bb35115b86b009d75962ef39632b679e8bbf0ff
name: python-geodrillcalc-help
arch: noarch
version: 0.4.3a0
epoch: 0
release: 1
summary: Development documents and examples for geodrillcalc
url: https://github.com/08dhuh/geodrillcalc
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-geodrillcalc-0.4.3a0-1.src.rpm
location_href: Packages/python-geodrillcalc-help-0.4.3a0-1.noarch.rpm
checksum_type: sha256
description:
  GeoDrillCalc is a Python package for calculating wellbore parameters and estimating costs associated with drilling operations. The package uses input data about aquifer layers and initial parameters to output wellbore specifications and cost estimates. It's designed for use in various applications, including web applications and other software tools.


  * **Aquifer Layer Analysis:** Determines the necessary wellbore specifications based on aquifer layers and depths.
  * **Wellbore Specifications:** Calculates screen length, screen diameter, open hole diameter, and pump parameters.
  * **Cost Estimation:** Provides detailed cost breakdowns including drilling rates, material costs, time rates, and other costs.
  * **Output Format:** Results are provided as dictionaries, which can be easily converted to JSON or used directly in other applications.


  Install GeoDrillCalc directly from PyPI using `pip`:

  ```bash
  pip install geodrillcalc
  ```



  A basic example of how to use GeoDrillCalc to calculate wellbore parameters and costs:

  ```python
  import geodrillcalc.geodrillcalc_interface as gdc


  aquifer_layer_table = {
      "aquifer_layer": [
          '100qa', '103utqd', '105utaf', '106utd', '107umta',
          '108umtd', '109lmta', '111lta', '114bse'
      ],
      "is_aquifer": [True, False, True, False, True, False, True, True, False],
      "depth_to_base": [3, 53, 112, 150, 150, 1000, 1000, 1221, 1421]  # in metres
  }


  initial_values = {
      "required_flow_rate": 4320,  # in litres per minute (L/min)
      "hydraulic_conductivity": 5,  # in metres per day (m/d)
      "average_porosity": 0.25,     # unitless (fractional)
      "bore_lifetime_year": 30,     # in years
      "groundwater_depth": 25,      # in metres
      "long_term_decline_rate": 1,  # in percentage per year (%/year)
      "allowable_drawdown": 25,     # in metres
      "safety_margin": 25,          # in percentage (%)
      "target_aquifer_layer": "109lmta", #the aquifer layer where the wellbore screen is installed. It’s the layer that you are primarily interested in extracting groundwater from or monitoring.
      "top_aquifer_layer": "100qa" #the uppermost aquifer layer
  }


  gci = gdc.GeoDrillCalcInterface()


  wbd = gci.calculate_and_return_wellbore_parameters(
      is_production_well=False,  # pass True for production wells, False for injection wells
      aquifer_layer_table=aquifer_layer_table,
      initial_input_params=initial_values,
      cost_rates=None,  # Optional: Dictionary containing cost rates for different stages. If None, default rates are used.
      margin_rates=None  # Optional: Dictionary containing margin rates for different cost components. If None, default margins are used.
  )


  if wbd.ready_for_calculation and wbd.ready_for_installation_output and wbd.ready_for_cost_output:
      
      result = wbd.export_results_to_dict()
      print(result)
  else:
      print("Calculation is not ready.")
  ```

  *Default Cost and Margin Rates*

  If `cost_rates` or `margin_rates` are not provided in the `calculate_and_return_wellbore_parameters` function, GeoDrillCalc will use default values. These default cost and margin rates can be found in the configuration files located at:

  - geodrillcalc/data/fallback_cost_rates.json
  - geodrillcalc/data/fallback_margin_rates.json


  *For information on aquifer codes and their definitions, refer to the [VVG Aquifer Codes](https://www.vvg.org.au/cb_pages/vaf.php).*



  The `export_results_to_dict()` method returns a dictionary containing the wellbore specifications and cost estimates. Overview of the results:



  - **screen_length**: The length of the well screen (in metres).
  - **screen_diameter**: The diameter of the well screen (in metres).
  - **open_hole_diameter**: The diameter of the open hole (in metres).
  - **pump_inlet_depth**: The depth at which the pump inlet is installed (in metres).
  - **minimum_pump_housing_diameter**: The minimum diameter required for the pump housing (in metres).
  - **casing_stage_table**: A table detailing the casing stages, including their top and bottom depths, casing diameter, and drill bit diameter.



  - **cost_estimation_table**: Provides a breakdown of estimated costs for various components and stages of the drilling process, including:
    - **stage**: The stage of the drilling process (e.g., drilling rates, materials, time rates, etc.).
    - **components**: The specific components within each stage (e.g., pilot hole, casing, etc.).
    - **low**, **base**, **high**: The estimated cost ranges (low, base, high) for each component.

  - **total_cost_table**: Summarises the total estimated costs for each stage of the process and the overall total cost:
    - **drilling_rates**: Costs related to drilling operations.
    - **materials**: Costs of materials used in the drilling process.
    - **others**: Additional costs not included in the other categories.
    - **time_rates**: Costs associated with time-based factors (e.g., rig standby, accommodation).
    - **total_cost**: The combined total cost of all stages and components.

  This detailed output allows users to understand the specifications of the wellbore and provides a comprehensive cost estimate for the drilling operation.





  - **screen_length**: `139.484` metres
  - **screen_length_error**: `(125.536, 153.433)` metres
  - **screen_diameter**: `0.1016` metres
  - **open_hole_diameter**: `0.1905` metres
  - **pump_inlet_depth**: `105` metres
  - **minimum_pump_housing_diameter**: `0.286` metres

  - **casing_stage_table(in metres)**:

  | casing_stages         | top    | bottom | casing | drill_bit |
  |-----------------------|--------|--------|--------|-----------|
  | pre_collar            | 0.0    | 12.0   | 0.762  | 0.9144    |
  | superficial_casing    | None   | None   | None   | None      |
  | pump_chamber_casing   | None   | None   | None   | None      |
  | intermediate_casing   | 0.0    | 990.0  | 0.1143 | 0.2159    |
  | screen_riser          | 980.0  | 1000.0 | 0.1016 | 0.1905    |
  | screen                | 1000.0 | 1139.0 | 0.1016 | 0.1905    |



  - **cost_estimation_table(in AUD)**:

  | Stage            | Components                  | Low          | Base                        | High         |
  |------------------|-----------------------------|--------------|-----------------------------|--------------|
  | drilling_rates   | pilot_hole                  | None         | 210,804.58                  | None         |
  | drilling_rates   | pre_collar                  | None         | 13,918.39                   | None         |
  | drilling_rates   | superficial_casing          | None         | None                        | None         |
  | drilling_rates   | pump_chamber_casing         | None         | None                        | None         |
  | drilling_rates   | intermediate_casing         | None         | 62,038.28                   | None         |
  | drilling_rates   | screen_riser                | None         | 455.33                      | None         |
  | drilling_rates   | screen                      | None         | 3,164.57                    | None         |
  | time_rates       | rig_standby_cost            | 1,600        | 1,800                       | 2,000        |
  | time_rates       | development_bail_surge_jet  | 25,000.00    | 31,250.00                   | 37,500.00    |
  | time_rates       | accommodation_cost          | 16,193.04    | 17,992.26                   | 19,791.49    |
  | time_rates       | site_telehandler_cost       | 2,698.84     | 2,998.71                    | 3,298.58     |
  | time_rates       | site_generator_fuel_cost    | 8,396.39     | 10,495.49                   | 12,594.58    |
  | materials        | cement                      | 4,116.69     | 4,786.85                    | 5,457.01     |
  | materials        | gravel                      | 204.79       | 238.13                      | 273.85       |
  | materials        | bentonite                   | 3,328.05     | 3,697.83                    | 4,067.62     |
  | materials        | drilling_fluid_and_lubricants | 5,145.34    | 5,717.04                    | 6,288.75     |
  | materials        | drilling_mud                | 2,714.99     | 3,016.65                    | 3,318.32     |
  | materials        | bore_flange_and_valve_spec  | 600          | 650                         | 700          |
  | materials        | cement_shoe                 | 3,330.00     | 3,700.00                    | 4,070.00     |
  | materials        | packer_lowering_assembly    | 4,680.00     | 5,200.00                    | 5,720.00     |
  | materials        | pre_collar                  | 2,438.40     | 3,048.00                    | 3,657.60     |
  | materials        | superficial_casing          | None         | None                        | None         |
  | materials        | pump_chamber_casing         | None         | None                        | None         |
  | materials        | intermediate_casing         | 313,121.44   | 354,552.94                  | 395,984.44   |
  | materials        | screen_riser                | 5,440.41     | 6,277.41                    | 7,114.41     |
  | materials        | screen                      | 38,218.96    | 44,036.11                   | 49,853.26    |
  | materials        | centraliser                 | 4,910.00     | 8,546.13                    | 11,497.50    |
  | others           | disinfection_drilling_plant | 1,500.00     | 1,500.00                    | 1,500.00     |
  | others           | mobilisation_demobilization | 59,974.21    | 59,974.21                   | 59,974.21    |
  | others           | installation_grouting_pre_collar | 3,600.00 | 3,600.00                    | 3,600.00     |
  | others           | wireline_logging            | 11,280.89    | 12,534.33                   | 13,787.76    |
  | others           | fabrication_installation    | 76,105.18    | 84,561.31                   | 93,017.45    |
  | others           | cement_casing               | 38,785.46    | 48,481.82                   | 58,178.18    |
  | others           | pack_gravel                 | 3,058.00     | 3,058.00                    | 3,058.00     |
  | others           | subcontract_welders         | 10,795.36    | 11,994.84                   | 13,194.33    |

  - **total_cost_table(in AUD)**:

  | Stage            | Low           | Base            | High          |
  |------------------|---------------|-----------------|---------------|
  | drilling_rates   | 230,581.02    | 290,381.15      | 350,181.28    |
  | materials        | 388,249.07    | 443,467.11      | 498,002.76    |
  | others           | 205,099.10    | 225,704.51      | 246,309.92    |
  | time_rates       | 53,888.27     | 64,536.46       | 75,184.65     |
  | **total_cost**   | **877,817.46**| **1,024,089.23**| **1,169,678.62**|


  **Notes:**

  - Fields with `None` indicate components or stages that are not required for this particular well. For example, "superficial_casing" and "pump_chamber_casing" might not be needed based on the well design and geology.

  - For `drilling_rates`, the total cost margins are considered with the pilot hole drilling cost margin times the total well depth. This provides an estimate based on the base cost of drilling a pilot hole adjusted for the well's depth.


pkgId: 3e1ff8b7ac56a3afcc45b2a021eb6f4577e7bbefe4b58bee8a629cfc6e8c8f97
name: python-geojson-modelica-translator-help
arch: noarch
version: 0.9.0
epoch: 0
release: 1
summary: Development documents and examples for geojson-modelica-translator
url: https://docs.urbanopt.net
rpm_license: BSD-4-Clause
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-geojson-modelica-translator-0.9.0-1.src.rpm
location_href: Packages/python-geojson-modelica-translator-help-0.9.0-1.noarch.rpm
checksum_type: sha256
description:
  [![image](https://github.com/urbanopt/geojson-modelica-translator/actions/workflows/ci.yml/badge.svg?branch=develop)](https://github.com/urbanopt/geojson-modelica-translator/actions/workflows/ci.yml)
  [![image](https://coveralls.io/repos/github/urbanopt/geojson-modelica-translator/badge.svg?branch=develop)](https://coveralls.io/github/urbanopt/geojson-modelica-translator?branch=develop)
  [![image](https://badge.fury.io/py/geojson-modelica-translator.svg)](https://badge.fury.io/py/geojson-modelica-translator)

  The GeoJSON Modelica Translator (GMT) is a one-way trip from GeoJSON in combination with a well-defined instance of the system parameters schema to a Modelica package with multiple buildings loads, energy transfer stations, distribution networks, and central plants. The project will eventually allow multiple paths to build up different district heating and cooling system topologies; however, the initial implementation is limited to 4GDHC and 5GDHC.

  Documentation can be found at [https://nrel.github.io/geojson-modelica-translator](https://nrel.github.io/geojson-modelica-translator)

  The project is motivated by the need to easily evaluate district energy systems. The goal is to eventually cover the various generations of heating and cooling systems as shown in the figure below. The need to move towards 5GDHC systems results in higher efficiencies and greater access to additional waste-heat sources.

  ![image](https://raw.githubusercontent.com/urbanopt/geojson-modelica-translator/develop/docs/images/des-generations.png)



  It is possible to test the GeoJSON to Modelica Translator (GMT) by simply installing the Python package and running the command line interface (CLI) with results from and URBANopt SDK set of results. However, to fully leverage the functionality of this package (e.g., running simulations), then you must also install the Modelica Buildings library (MBL) and Docker. Instructions for installing and configuring the MBL and Docker are available [here](docs/getting_started.rst).

  To simply scaffold out a Modelica package that can be inspected in a Modelica environment (e.g., Dymola, OpenModelica) then run the following code below up to the point of run-model. The example generates a complete 4th Generation District Heating and Cooling (4GDHC) system with time series loads that were generated from the URBANopt SDK using OpenStudio/EnergyPlus simulations.

  ``` bash
  pip install geojson-modelica-translator





  uo_des build-sys-param sys_param.json baseline_scenario.csv example_project.json


  uo_des create-model sys_param.json example_project.json model_from_sdk


  uo_des run-model model_from_sdk
  ```

  More example projects are available in an accompanying [example repository](https://github.com/urbanopt/geojson-modelica-translator-examples).



  The GMT is designed to enable "easy" swapping of building loads, district systems, and network topologies. Some of these functionalities are more developed than others, for instance swapping building loads between Spawn and RC models (using TEASER) is fleshed out; however, swapping between a first and fifth generation heating system has yet to be fully implemented.

  The diagram below is meant to illustrate the future proposed interconnectivity and functionality of the GMT project.

  ![image](https://raw.githubusercontent.com/urbanopt/geojson-modelica-translator/develop/docs/images/des-connections.png)

  As shown in the image, there are multiple building loads that can be deployed with the GMT and are described in the [Building Load Models](#building-load-models) section below. These models, and the associated design parameters, are required to create a fully runnable Modelica model. The GMT leverages two file formats for generating the Modelica project and are the GeoJSON feature file and a System Parameter JSON file. See the more [comprehensive documentation on the GMT](https://docs.urbanopt.net/geojson-modelica-translator/) or the [documentation on URBANopt SDK](https://docs.urbanopt.net/).



  The building loads can be defined multiple ways depending on the fidelity of the required models. Each of the building load models are easily replaced using configuration settings within the System Parameters file. The 4 different building load models include:

  1. **Time Series in Watts**: This building load is the total heating, cooling, and domestic hot water loads represented in a CSV type file (MOS file). The units are Watts and should be reported at an hour interval; however, finer resolution is possible. The load is defined as the load seen by the ETS.
  2. **Time Series as mass flow rate and delta temperature**: This building load is similar to the other Time Series model but uses the load as seen by the ETS in the form of mass flow rate and delta temperature. The file format is similar to the other Time Series model but the columns are mass flow rate and delta temperature for heating and cooling separately.
  3. **RC Model**: This model leverages the TEASER framework to generate an RC model with the correct coefficients based on high level parameters that are extracted from the GeoJSON file including building area and building type.
  4. **Spawn of EnergyPlus**: This model uses EnergyPlus models to represent the thermal zone heat balance portion of the models while using Modelica for the remaining components. Spawn of EnergyPlus is still under development and currently only works on Linux-based systems.



  1. Create a branch named `Release 0.x.`
  1. Update version in pyproject.toml
  1. Update CHANGELOG using GitHub's "Autogenerate Change Log" feature, using `develop` as the target
  1. After tests pass, merge branch into develop
  1. From local command line, merge develop into main with: `git checkout main; git pull; git merge --ff-only origin develop; git push`
  1. In GitHub, tag the release against main. Copy and paste the changelog entry into the notes. Verify the release is posted to PyPI.



  During development we can [serve docs locally](https://squidfunk.github.io/mkdocs-material/creating-your-site/#previewing-as-you-write) and view updates as they are made.

     1. Start a documentation update branch: `git switch -c <branch_name>`
     1. `poetry run mkdocs serve`
     1. Point browser to [http://127.0.0.1:8000/](http://127.0.0.1:8000/)

  - To deploy, push a commit in the `docs` folder to the `main` branch
  - Wait a few minutes, then verify the new documentation on the [docs website](https://nrel.github.io/geojson-modelica-translator/)


pkgId: ce8f38c965b1f3154c01ae997102c50877ea8f384890a5c8fe5ab87e595198ea
name: python-geojson-pydantic-help
arch: noarch
version: 1.2.0
epoch: 0
release: 1
summary: Development documents and examples for geojson-pydantic
url: https://pypi.org/project/geojson-pydantic/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-geojson-pydantic-1.2.0-1.src.rpm
location_href: Packages/python-geojson-pydantic-help-1.2.0-1.noarch.rpm
checksum_type: sha256
description:
  **Documentation**: <a href="https://developmentseed.org/geojson-pydantic/" target="_blank">https://developmentseed.org/geojson-pydantic/</a>


pkgId: ce990b4b43bd21edd87054723d776784e9638c265b0a01176ccc73d89f1f0427
name: python-geolink-formatter-help
arch: noarch
version: 2.0.6
epoch: 0
release: 1
summary: Development documents and examples for geolink-formatter
url: https://gitlab.com/gf-bl/python-geolink-formatter
rpm_license: BSD
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-geolink-formatter-2.0.6-1.src.rpm
location_href: Packages/python-geolink-formatter-help-2.0.6-1.noarch.rpm
checksum_type: sha256
description:
  |license| |python version| |format| |status| |build status| |coverage report| |dependencies| |code quality|
  This is a small library, meant to be used in combination with OEREBlex. It is capable of parsing a received
  geoLink response (XML) and converting it to multiple formats, such as HTML, which can be styled for
  presentation.
  For detailed information, please refer to the online documentation:
  https://openoereb.github.io/geolink_formatter/


pkgId: 40df105e9c991babf1e7792c0dcb1f20d9b4893b93b12b3fec124fc263c08064
name: python-geomagindices-help
arch: noarch
version: 1.5.1
epoch: 0
release: 1
summary: Development documents and examples for geomagindices
url: https://pypi.org/project/geomagindices/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-geomagindices-1.5.1-1.src.rpm
location_href: Packages/python-geomagindices-help-1.5.1-1.noarch.rpm
checksum_type: sha256
description:
  ```sh
  python Examples/PlotIndices.py 2015-01-01 2016-01-01
  ```
  ![2015 Ap F10.7](https://github.com/space-physics/geomagindices/blob/main/src/geomagindices/tests/2015.png)

  We should add readers for the new post-SWPC data sources, from 2018 onward as noted at:
  https://www.celestrak.com/SpaceData/SpaceWx-format.php
  * [Kp, Ap](ftp://ftp.gfz-potsdam.de/pub/home/obs/kp-ap/wdc/)
  * [f10.7](ftp://ftp.geolab.nrcan.gc.ca/data/solar_flux/daily_flux_values/fluxtable.txt)
  Let us know via GitHub Issue if you want this new data.


pkgId: 8c94b76ef72a3ad12647caf77798b93fb813503efbc7c94b0866aa19277f2216
name: python-geoservercloud-help
arch: noarch
version: 0.3.0
epoch: 0
release: 1
summary: Development documents and examples for geoservercloud
url: https://pypi.org/project/geoservercloud/
rpm_license: BSD-2-Clause
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-geoservercloud-0.3.0-1.src.rpm
location_href: Packages/python-geoservercloud-help-0.3.0-1.noarch.rpm
checksum_type: sha256
description:
  From PyPI:

  ```shell
  pip install geoservercloud
  ```

  From git repository:

  ```shell
  poetry install
  ```



  ```python
  from geoservercloud import GeoServerCloud
  geoserver = GeoServerCloud(
      url="http://localhost:9090/geoserver/cloud/",
      user="admin",
      password="geoserver",
  )
  geoserver.create_workspace("newworkspace")
  ```


pkgId: 65aa9fecef7d63ec3f2f916d23b705bc772ddf3e072cf88752d6bd564fd7f26e
name: python-geosh-help
arch: noarch
version: 0.0.1
epoch: 0
release: 1
summary: Development documents and examples for geosh
url: https://github.com/Adre17/geosh
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-geosh-0.0.1-1.src.rpm
location_href: Packages/python-geosh-help-0.0.1-1.noarch.rpm
checksum_type: sha256
description:
  > Grechi Umberto, [www.sofhare.com](https://www.sofhare.com/)



  -   [About _hvsrpy_](#About-hvsrpy)
  -   [Why use _hvsrpy_](#Why-use-hvsrpy)
  -   [A Comparison of _hvsrpy_ with _Geopsy_](#A-comparison-of-hvsrpy-with-Geopsy)
  -   [Getting Started](#Getting-Started)
  -   [Additional Comparisons between _hvsrpy_ and _Geopsy_](#Additional-Comparisons-between-hvsrpy-and-Geopsy)
      -   [Multiple Windows](#Multiple-Windows)
      -   [Single Window](#Single-Window)



  `geosh` is an open-source Python package for Geo Utilities plugin.



  hvsrpy

  > Joseph Vantassel. (2020). jpvantassel/hvsrpy: latest (Concept). Zenodo.
  > [http://doi.org/10.5281/zenodo.3666956](http://doi.org/10.5281/zenodo.3666956)

  Lognormal statistics and fully-automated frequency-domain window-rejection algorithm.

  > Cox, B. R., Cheng, T., Vantassel, J. P., & Manuel, L. (2020). "A statistical
  > representation and frequency-domain window-rejection algorithm for single-station
  > HVSR measurements. Geophysical Journal International, 221(3), 2170–2183.
  > https://doi.org/10.1093/gji/ggaa119

  Statistical approach to incorporate azimuthal variability.

  > Cheng, T., Cox, B. R., Vantassel, J. P., and Manuel, L. (2020). "A
  > statistical approach to account for azimuthal variability in single-station
  > HVSR measurements." Geophysical Journal International, 223(2), 1040–1053.
  > https://doi.org/10.1093/gji/ggaa342

  Statistical approach to incorporate spatial variability.

  > Cheng, T., Hallal, M. M., Vantassel, J. P., and Cox, B. R., (2021).
  > "Estimating Unbiased Statistics for Fundamental Site Frequency Using
  > Spatially Distributed HVSR Measurements and Voronoi Tessellation.
  > J. Geotech. Geoenviron. Eng. 147, 04021068.
  > https://doi.org/10.1061/(ASCE)GT.1943-5606.0002551

  SESAME clarity and reliability criteria for microtremor HVSR.

  > SESAME. (2004). Guidelines for the Implementation of the H/V Spectral Ratio
  > Technique on Ambient Vibrations Measurements, Processing, and Interpretation.
  > European Commission - Research General Directorate, 62, European Commission -
  > Research General Directorate.

  Computation of HVSR under the diffuse field assumption.

  > Sánchez-Sesma, F.J., Rodríguez, M., Iturrarán-Viveros, U., Luzón, F.,
  > Campillo, M., Margerin, L., García-Jerez, A., Suarez, M., Santoyo, M.A.,
  > Rodríguez-Castellanos, A. (2011). A theory for microtremor H/V spectral
  > ratio: application for a layered medium: Theory for microtremor H/V spectral
  > ratio. Geophysical Journal International 186, 221–225.
  > https://doi.org/10.1111/j.1365-246X.2011.05064.x

  Power spectral density (PSD) calculation.

  > Welch, P., (1967). The use of fast Fourier transform for the estimation
  > of power spectra: a method based on time averaging over short, modified
  > periodograms. IEEE Transactions on audio and electroacoustics, 15(2), pp.70-73.

  New high noise model (NHNM) and new low noise model (NLNM).

  > Peterson, J., (1993). Observation and Modeling of Seismic Background
  > Noise (Open-File Report No. 93–322). U.S. Geologic Survey, Albuquerque, New Mexico.


pkgId: 8ec97b912a15e994f8e91a6094ef315e64b00f3e323013e64f109ad4a8116ce3
name: python-geospatial-analysis-help
arch: noarch
version: 0.0.1
epoch: 0
release: 1
summary: Development documents and examples for geospatial-analysis
url: https://github.com/HammamiKhaled/geospatial-analysis
rpm_license: MIT License
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-geospatial-analysis-0.0.1-1.src.rpm
location_href: Packages/python-geospatial-analysis-help-0.0.1-1.noarch.rpm
checksum_type: sha256
description:
  [![image](https://img.shields.io/pypi/v/geospatial-analysis.svg)](https://pypi.python.org/pypi/geospatial-analysis)
  [![image](https://img.shields.io/conda/vn/conda-forge/geospatial-analysis.svg)](https://anaconda.org/conda-forge/geospatial-analysis)


  **A python package demo for geospatial analysis**


  -   Free software: MIT License
  -   Documentation: https://HammamiKhaled.github.io/geospatial-analysis




  -   TODO


pkgId: fd4c63363731d3fb434752ee0ef6f02cf4c6bd654457771f8459b68b452fe5d6
name: python-geouned-help
arch: noarch
version: 1.5.1
epoch: 0
release: 1
summary: Development documents and examples for geouned
url: https://github.com/GEOUNED-org
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-geouned-1.5.1-1.src.rpm
location_href: Packages/python-geouned-help-1.5.1-1.noarch.rpm
checksum_type: sha256
description:
  [![CI testing](https://github.com/GEOUNED-org/GEOUNED/actions/workflows/ci.yml/badge.svg?branch=main)](https://github.com/GEOUNED-org/GEOUNED/actions/workflows/ci.yml)
  [![Upload Python Package](https://github.com/GEOUNED-org/GEOUNED/actions/workflows/python-publish.yml/badge.svg)](https://github.com/GEOUNED-org/GEOUNED/actions/workflows/python-publish.yml)
  [![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg?style=flat-square)](https://github.com/psf/black)
  [![documentation release](https://github.com/GEOUNED-org/GEOUNED/actions/workflows/documentation_release.yml/badge.svg)](https://github.com/GEOUNED-org/GEOUNED/actions/workflows/documentation_release.yml)
  [![PyPI](https://img.shields.io/pypi/v/geouned?&label=PyPI)](https://pypi.org/project/geouned/)

  [![Anaconda-Server Badge](https://anaconda.org/conda-forge/geouned/badges/version.svg)](https://anaconda.org/conda-forge/geouned)
  [![Anaconda-Server Badge](https://anaconda.org/conda-forge/geouned/badges/platforms.svg)](https://anaconda.org/conda-forge/geouned)
  [![Anaconda-Server Badge](https://anaconda.org/conda-forge/geouned/badges/downloads.svg)](https://anaconda.org/conda-forge/geouned)



  A tool to convert from CAD to CSG & CSG to CAD for Monte Carlo transport codes (MCNP & OpenMC).
  This repository contains the implementation of the algorithm presented in the paper [GEOUNED: A new conversion tool from CAD to Monte Carlo geometry](https://doi.org/10.1016/j.net.2024.01.052).

  See the [online documentation](https://geouned-org.github.io/GEOUNED/index.html) for installation, usage and API reference.



  ```
  @article{CATALAN2024,
    author = {J.P. Catalán and P. Sauvan and J. García and J. Alguacil and F. Ogando and J. Sanz},
    title = {GEOUNED: A new conversion tool from CAD to Monte Carlo geometry},
    journal = {Nuclear Engineering and Technology},
    year = {2024},
    issn = {1738-5733},
    doi = {https://doi.org/10.1016/j.net.2024.01.052}
  }
  ```

rpm_license:
  EUROPEAN UNION PUBLIC LICENCE v. 1.2 EUPL © the European Union 2007, 2016  This European Union Public Licence (the ‘EUPL’) applies to the Work (as defined below) which is provided under the terms of this Licence. Any use of the Work, other than as authorised under this Licence is prohibited (to the extent such use is covered by a right of the copyright holder of the Work).  The Work is provided under the terms of this Licence when the Licensor (as defined below) has placed the following notice immediately following the copyright notice for the Work:  Licensed under the EUPL  or has expressed by any other means his willingness to license under the EUPL.  1. Definitions  In this Licence, the following terms have the following meaning:  - ‘The Licence’: this Licence.  - ‘The Original Work’: the work or software distributed or communicated by the Licensor under this Licence, available as Source Code and also as Executable Code as the case may be.  - ‘Derivative Works’: the works or software that could be created by the Licensee, based upon the Original Work or modifications thereof. This Licence does not define the extent of modification or dependence on the Original Work required in order to classify a work as a Derivative Work; this extent is determined by copyright law applicable in the country mentioned in Article 15.  - ‘The Work’: the Original Work or its Derivative Works.  - ‘The Source Code’: the human-readable form of the Work which is the most convenient for people to study and modify.  - ‘The Executable Code’: any code which has generally been compiled and which is meant to be interpreted by a computer as a program.  - ‘The Licensor’: the natural or legal person that distributes or communicates the Work under the Licence.  - ‘Contributor(s)’: any natural or legal person who modifies the Work under the Licence, or otherwise contributes to the creation of a Derivative Work.  - ‘The Licensee’ or ‘You’: any natural or legal person who makes any usage of the Work under the terms of the Licence.  - ‘Distribution’ or ‘Communication’: any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, online or offline, copies of the Work or providing access to its essential functionalities at the disposal of any other natural or legal person.  2. Scope of the rights granted by the Licence  The Licensor hereby grants You a worldwide, royalty-free, non-exclusive, sublicensable licence to do the following, for the duration of copyright vested in the Original Work:  - use the Work in any circumstance and for all usage, - reproduce the Work, - modify the Work, and make Derivative Works based upon the Work, - communicate to the public, including the right to make available or display the Work or copies thereof to the public and perform publicly, as the case may be, the Work, - distribute the Work or copies thereof, - lend and rent the Work or copies thereof, - sublicense rights in the Work or copies thereof.  Those rights can be exercised on any media, supports and formats, whether now known or later invented, as far as the applicable law permits so.  In the countries where moral rights apply, the Licensor waives his right to exercise his moral right to the extent allowed by law in order to make effective the licence of the economic rights here above listed.  The Licensor grants to the Licensee royalty-free, non-exclusive usage rights to any patents held by the Licensor, to the extent necessary to make use of the rights granted on the Work under this Licence.  3. Communication of the Source Code  The Licensor may provide the Work either in its Source Code form, or as Executable Code. If the Work is provided as Executable Code, the Licensor provides in addition a machine-readable copy of the Source Code of the Work along with each copy of the Work that the Licensor distributes or indicates, in a notice following the copyright notice attached to the Work, a repository where the Source Code is easily and freely accessible for as long as the Licensor continues to distribute or communicate the Work.  4. Limitations on copyright  Nothing in this Licence is intended to deprive the Licensee of the benefits from any exception or limitation to the exclusive rights of the rights owners in the Work, of the exhaustion of those rights or of other applicable limitations thereto.  5. Obligations of the Licensee  The grant of the rights mentioned above is subject to some restrictions and obligations imposed on the Licensee. Those obligations are the following:  Attribution right: The Licensee shall keep intact all copyright, patent or trademarks notices and all notices that refer to the Licence and to the disclaimer of warranties. The Licensee must include a copy of such notices and a copy of the Licence with every copy of the Work he/she distributes or communicates. The Licensee must cause any Derivative Work to carry prominent notices stating that the Work has been modified and the date of modification.  Copyleft clause: If the Licensee distributes or communicates copies of the Original Works or Derivative Works, this Distribution or Communication will be done under the terms of this Licence or of a later version of this Licence unless the Original Work is expressly distributed only under this version of the Licence — for example by communicating ‘EUPL v. 1.2 only’. The Licensee (becoming Licensor) cannot offer or impose any additional terms or conditions on the Work or Derivative Work that alter or restrict the terms of the Licence.  Compatibility clause: If the Licensee Distributes or Communicates Derivative Works or copies thereof based upon both the Work and another work licensed under a Compatible Licence, this Distribution or Communication can be done under the terms of this Compatible Licence. For the sake of this clause, ‘Compatible Licence’ refers to the licences listed in the appendix attached to this Licence. Should the Licensee's obligations under the Compatible Licence conflict with his/her obligations under this Licence, the obligations of the Compatible Licence shall prevail.  Provision of Source Code: When distributing or communicating copies of the Work, the Licensee will provide a machine-readable copy of the Source Code or indicate a repository where this Source will be easily and freely available for as long as the Licensee continues to distribute or communicate the Work.  Legal Protection: This Licence does not grant permission to use the trade names, trademarks, service marks, or names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the copyright notice.  6. Chain of Authorship  The original Licensor warrants that the copyright in the Original Work granted hereunder is owned by him/her or licensed to him/her and that he/she has the power and authority to grant the Licence.  Each Contributor warrants that the copyright in the modifications he/she brings to the Work are owned by him/her or licensed to him/her and that he/she has the power and authority to grant the Licence.  Each time You accept the Licence, the original Licensor and subsequent Contributors grant You a licence to their contributions to the Work, under the terms of this Licence.  7. Disclaimer of Warranty  The Work is a work in progress, which is continuously improved by numerous Contributors. It is not a finished work and may therefore contain defects or ‘bugs’ inherent to this type of development.  For the above reason, the Work is provided under the Licence on an ‘as is’ basis and without warranties of any kind concerning the Work, including without limitation merchantability, fitness for a particular purpose, absence of defects or errors, accuracy, non-infringement of intellectual property rights other than copyright as stated in Article 6 of this Licence.  This disclaimer of warranty is an essential part of the Licence and a condition for the grant of any rights to the Work.  8. Disclaimer of Liability  Except in the cases of wilful misconduct or damages directly caused to natural persons, the Licensor will in no event be liable for any direct or indirect, material or moral, damages of any kind, arising out of the Licence or of the use of the Work, including without limitation, damages for loss of goodwill, work stoppage, computer failure or malfunction, loss of data or any commercial damage, even if the Licensor has been advised of the possibility of such damage. However, the Licensor will be liable under statutory product liability laws as far such laws apply to the Work.  9. Additional agreements  While distributing the Work, You may choose to conclude an additional agreement, defining obligations or services consistent with this Licence. However, if accepting obligations, You may act only on your own behalf and on your sole responsibility, not on behalf of the original Licensor or any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against such Contributor by the fact You have accepted any warranty or additional liability.  10. Acceptance of the Licence  The provisions of this Licence can be accepted by clicking on an icon ‘I agree’ placed under the bottom of a window displaying the text of this Licence or by affirming consent in any other similar way, in accordance with the rules of applicable law. Clicking on that icon indicates your clear and irrevocable acceptance of this Licence and all of its terms and conditions.  Similarly, you irrevocably accept this Licence and all of its terms and conditions by exercising any rights granted to You by Article 2 of this Licence, such as the use of the Work, the creation by You of a Derivative Work or the Distribution or Communication by You of the Work or copies thereof.  11. Information to the public  In case of any Distribution or Communication of the Work by means of electronic communication by You (for example, by offering to download the Work from a remote location) the distribution channel or media (for example, a website) must at least provide to the public the information requested by the applicable law regarding the Licensor, the Licence and the way it may be accessible, concluded, stored and reproduced by the Licensee.  12. Termination of the Licence  The Licence and the rights granted hereunder will terminate automatically upon any breach by the Licensee of the terms of the Licence.  Such a termination will not terminate the licences of any person who has received the Work from the Licensee under the Licence, provided such persons remain in full compliance with the Licence.  13. Miscellaneous  Without prejudice of Article 9 above, the Licence represents the complete agreement between the Parties as to the Work.  If any provision of the Licence is invalid or unenforceable under applicable law, this will not affect the validity or enforceability of the Licence as a whole. Such provision will be construed or reformed so as necessary to make it valid and enforceable.  The European Commission may publish other linguistic versions or new versions of this Licence or updated versions of the Appendix, so far this is required and reasonable, without reducing the scope of the rights granted by the Licence. New versions of the Licence will be published with a unique version number.  All linguistic versions of this Licence, approved by the European Commission, have identical value. Parties can take advantage of the linguistic version of their choice.  14. Jurisdiction  Without prejudice to specific agreement between parties,  - any litigation resulting from the interpretation of this License, arising between the European Union institutions, bodies, offices or agencies, as a Licensor, and any Licensee, will be subject to the jurisdiction of the Court of Justice of the European Union, as laid down in article 272 of the Treaty on the Functioning of the European Union,  - any litigation arising between other parties and resulting from the interpretation of this License, will be subject to the exclusive jurisdiction of the competent court where the Licensor resides or conducts its primary business.  15. Applicable Law  Without prejudice to specific agreement between parties,  - this Licence shall be governed by the law of the European Union Member State where the Licensor has his seat, resides or has his registered office,  - this licence shall be governed by Belgian law if the Licensor has no seat, residence or registered office inside a European Union Member State.  Appendix  ‘Compatible Licences’ according to Article 5 EUPL are:  - GNU General Public License (GPL) v. 2, v. 3 - GNU Affero General Public License (AGPL) v. 3 - Open Software License (OSL) v. 2.1, v. 3.0 - Eclipse Public License (EPL) v. 1.0 - CeCILL v. 2.0, v. 2.1 - Mozilla Public Licence (MPL) v. 2 - GNU Lesser General Public Licence (LGPL) v. 2.1, v. 3 - Creative Commons Attribution-ShareAlike v. 3.0 Unported (CC BY-SA 3.0) for works other than software - European Union Public Licence (EUPL) v. 1.1, v. 1.2 - Québec Free and Open-Source Licence — Reciprocity (LiLiQ-R) or Strong Reciprocity (LiLiQ-R+).  The European Commission may update this Appendix to later versions of the above licences without producing a new version of the EUPL, as long as they provide the rights granted in Article 2 of this Licence and protect the covered Source Code from exclusive appropriation.  All other changes or additions to this Appendix require the production of a new EUPL version.


pkgId: 0e9dd30516cd442877ed57d0c36222fff60165a50ca920f5d368d2b353ebe40c
name: python-gestell-help
arch: noarch
version: 1.0.0
epoch: 0
release: 1
summary: Development documents and examples for gestell
url: https://pypi.org/project/gestell/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gestell-1.0.0-1.src.rpm
location_href: Packages/python-gestell-help-1.0.0-1.noarch.rpm
checksum_type: sha256
description:
  ![license](https://img.shields.io/badge/license-MIT-blue)
  ![version](https://img.shields.io/badge/version-1.0.0-blue)
  [![Coverage Status](https://coveralls.io/repos/github/Gestell-AI/python-sdk/badge.svg?branch=master)](https://coveralls.io/github/Gestell-AI/python-sdk?branch=master)
  [![CircleCI](https://dl.circleci.com/status-badge/img/circleci/7sUmZuDYQ6cd8WbCiCCnfR/VPonbpR7NEQSaXxQngcCGW/tree/master.svg?style=svg)](https://dl.circleci.com/status-badge/redirect/circleci/7sUmZuDYQ6cd8WbCiCCnfR/VPonbpR7NEQSaXxQngcCGW/tree/master)

  A fully featured SDK with extensive code completion and typesystems for interacting with the Gestell Platform. Full featured support for Python 3.X. Uses asynchronous coroutines by design.

  ![Project Preview](https://github.com/Gestell-AI/python-sdk/blob/master/preview.gif?raw=true)



  First, get an API Key from <https://platform.gestell.ai>. Then install `gestell-sdk`:

  ```bash
  pip install gestell-sdk
  ```

  Or...

  ```bash
  uv add gestell-sdk
  ```

  Second, load the API Key into your terminal session, or, pass it into the SDK:

  ```bash

  export GESTELL_API_KEY = "..."
  ```

  Or load it directly in the client:

  ```python
  import asyncio
  import json
  from gestell-sdk import Gestell


  async def main():
      gestell = Gestell(key='...', url='...', debug=True)

  if __name__ == '__main__':
      asyncio.run(main())
  ```

  **Gestell will also read and load these environment variables from a `.env` file.**

  Finally, start using the Gestell Platform SDK. The SDK can be used both on the client and server side. A public facing app should use it server side only due to the API Key being passed into the SDK and requests:

  ```python
  import asyncio
  import json
  from gestell-sdk import Gestell


  async def main():
      gestell = Gestell()
      try:
          list_response = await gestell.collection.list()
          print('Organizations:')
          print(json.dumps(list_response.to_dict(), indent=4))
      except Exception as e:
          print(f'Error listing organizations: {e}')


  if __name__ == '__main__':
      asyncio.run(main())
  ```



  You can review guides on common workflows and use cases for the Gestell Platform by going to <https://gestell.ai/docs>. Here are the most common use cases:

  1. [Create a collection and upload documents to it](https://gestell.ai/docs/quick-start)

  2. [Prompt a collection](https://gestell.ai/docs/prompt)

  3. [Gather all labels from a collection](https://gestell.ai/docs/labels)

  4. [Gather all tables from a collection](https://gestell.ai/docs/tables)



  All workflows in the SDK use the [ruff](https://github.com/astral-sh/ruff) and [uv](https://github.com/astral-sh/uv).

  Opening an issue to address your concern is recommended. However, if you plan to submit a pull request (PR), please adhere to the following:

   1. **Align with the Repo Structure**: Organize canonical functionality within the appropriate folders. Provide clear documentation and usage annotations in the base class structures.

   2. **Pass All Unit Tests**: Ensure all `pytest` unit tests pass and maintain near full code coverage.

   3. **Provide a Detailed PR Description**: Clearly outline the changes made and the specific issues they resolve in your pull request.

  The workflow is as follows:

  ```bash

  uv venv
  uv build


  ruff check
  ruff format
  uv run pytest
  uv run coveralls


  cd ..
  uv init test
  cd test
  uv add ../python-sdk
  ```


pkgId: ae49dff666278465f19e3eb4eac543ec20c0cf84ea2a3d4b6d94ce2ec0743b34
name: python-gfinancelib-help
arch: noarch
version: 1.41
epoch: 0
release: 1
summary: Development documents and examples for gfinancelib
url: https://pypi.org/project/gfinancelib/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gfinancelib-1.41-1.src.rpm
location_href: Packages/python-gfinancelib-help-1.41-1.noarch.rpm
checksum_type: sha256
description:
  This library provides a set of functions for financial analysis using the `yfinance` and `ta` libraries. It includes functionalities for retrieving stock prices, calculating financial indicators, and sending notifications.




  Fetches the last closing price of the specified ticker.

  - **Parameters:**
    - `ticker` (str): The ticker symbol of the stock.
  - **Returns:**
    - `float`: The last closing price, or `None` if an error occurs.


  Calculates the Return on Investment (ROI) for the specified ticker and buy price.

  - **Parameters:**
    - `ticker` (str): The ticker symbol of the stock.
    - `buy` (float): The buy price of the stock.
  - **Returns:**
    - `float`: The ROI in percentage, or `None` if an error occurs.


  Calculates the Relative Strength Index (RSI) for the specified ticker.

  - **Parameters:**
    - `ticker` (str): The ticker symbol of the stock.
    - `periods` (int): The number of periods to use for the RSI calculation.
    - `chart_data` (str): The period of chart data to use.
    - `timeframe` (str): The interval of the chart data.
  - **Returns:**
    - `float`: The RSI value, or `None` if an error occurs.


  Calculates the Exponential Moving Average (EMA) for the specified ticker.

  - **Parameters:**
    - `ticker` (str): The ticker symbol of the stock.
    - `periods` (int): The number of periods to use for the EMA calculation.
    - `chart_data` (str): The period of chart data to use.
    - `timeframe` (str): The interval of the chart data.
  - **Returns:**
    - `float`: The EMA value, or `None` if an error occurs.


  Calculates the profit for the specified ticker, buy price, and quantity.

  - **Parameters:**
    - `ticker` (str): The ticker symbol of the stock.
    - `buy` (float): The buy price of the stock.
    - `qty` (float): The quantity of the stock.
  - **Returns:**
    - `float`: The profit, or `None` if an error occurs.


  Calculates the invested amount for the specified buy price and quantity.

  - **Parameters:**
    - `buy` (float): The buy price of the stock.
    - `qty` (float): The quantity of the stock.
  - **Returns:**
    - `float`: The invested amount, or `None` if an error occurs.


  Sends a message via Telegram.

  - **Parameters:**
    - `token` (str): The Telegram bot token.
    - `id` (str): The chat ID.
    - `message` (str): The message to send.
  - **Returns:**
    - `dict`: The response from the Telegram API, or `None` if an error occurs.


  Opens the Yahoo Finance chart for the specified ticker in a web browser.

  - **Parameters:**
    - `ticker` (str): The ticker symbol of the stock.


  Opens the Yahoo Finance news page in a web browser.


  Fetches the exchange rate for the specified currency pair.

  - **Parameters:**
    - `pair` (str): The currency pair (e.g., "USDJPY").
  - **Returns:**
    - `float`: The exchange rate, or `None` if an error occurs.


  Fetches the all-time high (ATH) for the specified ticker.

  - **Parameters:**
    - `ticker` (str): The ticker symbol of the stock.
  - **Returns:**
    - `float`: The all-time high value, or `None` if an error occurs.


  Fetches the currency in which the specified ticker is traded.

  - **Parameters:**
    - `ticker` (str): The ticker symbol of the stock.
  - **Returns:**
    - `str`: The currency, or `None` if an error occurs.


  Fetches the exchange where the specified ticker is traded.

  - **Parameters:**
    - `ticker` (str): The ticker symbol of the stock.
  - **Returns:**
    - `str`: The exchange, or `None` if an error occurs.


  Clears the console screen.

  - **Parameters:** None
  - **Returns:** None



  Here are a few examples to help you get started:

  ```python

  print(last("AAPL"))


  print(roi("AAPL", 120))


  print(rsi("AAPL", 14, "2y", "1h"))


  print(ema("AAPL", 200, "2y", "1h"))


  print(profit("AAPL", 120, 10))


  print(invested(120, 10))


  telegram("<your_token>", "<your_chat_id>", "Hello from the bot!")


  ychart("AAPL")


  ynews()


  print(change("USD"))


  print(ath("AAPL"))


  print(get_currency("AAPL"))


  print(get_exchange("AAPL"))


  clean()
  ```



  - **Dependencies**: This library requires the `yfinance`, `requests`, `ta`, `pandas`, and `webbrowser` modules.
  - **Installation**: You can install the necessary modules using:
    ```bash
    pip install yfinance requests ta pandas
    ```

  - Created by Francesco Vito Giotta (LemonPower21)
  - LinkedIn: https://www.linkedin.com/in/francesco-vito-giotta-969938314/
  - GitHub: https://github.com/LemonPower21/gfinancelib


pkgId: 3148a15e9827b23e6a49a4a940ce741b67bf6720de4b42a7e39beb64f322b932
name: python-gfthings-help
arch: noarch
version: 0.5.0
epoch: 0
release: 1
summary: Development documents and examples for gfthings
url: https://pypi.org/project/gfthings/
rpm_license: CC BY-NC-SA 4.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gfthings-0.5.0-1.src.rpm
location_href: Packages/python-gfthings-help-0.5.0-1.noarch.rpm
checksum_type: sha256
description:
  This Python program will generate several different kinds of gridfinity
  compatible objects for 3D printing.
  Gridfinity is an open source storage system best introduced
  [in this video](https://www.youtube.com/watch?v=ra_9zU-mnl8) and then this
  [diagram](https://gridfinity.xyz/specification/).
  Look on [thangs](thangs.com) and
  [printables](printables.com) for more compatible parts.
  Setup, You can install with pipx.
      sudo apt install pipx
      pipx install gfthings
  If you want to modify gfthings then build it with poetry.
      sudo apt install pipx
      pipx install poetry
      poetry add ocp-vscode
      poetry install
  If you choose this option then you must prefix your commands with
  `poetry run`
  Copyright (C) Paul Bone
  Distributed under: CC BY-NC-SA 4.0
  https://creativecommons.org/licenses/by-nc-sa/4.0/


pkgId: e493291edcbff54f320d01c6929b5fae96fac413e83720c2876da0f85ddf13a8
name: python-gg-transfer-help
arch: noarch
version: 0.2.13
epoch: 0
release: 1
summary: Development documents and examples for gg-transfer
url: https://github.com/matteotenca/gg-transfer
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gg-transfer-0.2.13-1.src.rpm
location_href: Packages/python-gg-transfer-help-0.2.13-1.noarch.rpm
checksum_type: sha256
description:
  ![PyPI - Status](https://img.shields.io/pypi/status/gg-transfer)
  ![PyPI - License](https://img.shields.io/pypi/l/gg-transfer?color=blue)
  ![PyPI - Python Version](https://img.shields.io/pypi/pyversions/gg-transfer)

  This tool is intended to send/receive short text messages or whole binary files over audio.
  It uses `ggwave` library ([https://github.com/ggerganov/ggwave](https://github.com/ggerganov/ggwave)) to encode text messages or binary files, send
  them over the audio interface, or decode them from the microphone.
  It can be used - and its main purpose is - to send data through radio transceivers. See https://github.com/matteotenca/fm-transfer
  This is a shell front-end which implements the sending/receiving of bare text or whole binary files, which are encoded in Base64.
  In `--file-transfer` mode, the file is opened and read all at once, then is encoded in Base64, and a header in JSON
  with some info about the file itself is sent. The Base64 encoded string is split into 132 bytes/long chunks, and a
  CRC32 is added at the beginning of the block to reach the maximum block size allowed by `ggwave`, 140 bytes.
  The CRCs are inserted shifted by one block to be sure the blocks arrive in the right order. At last, the checksum of the whole file
  is checked against the one received in the header.
  The standard behaviour is to play/record audio to/from the default audio devices.
  There are nine different protocols to send data:
  ```
      0 = Normal (11,17 Bytes/s - 1875 Hz to 6375 Hz)
      1 = Fast (16,76 Bytes/s - 1875 Hz to 6375 Hz)
      2 = Fastest (33,52 Bytes/s 1875 Hz to 6375 Hz)
      3 = [U] Normal (11,17 Bytes/s - 15000 Hz to 19500 Hz)
      4 = [U] Fast (16,76 Bytes/s - 15000 Hz to 19500 Hz)
      5 = [U] Fastest (33,52 Bytes/s - 15000 Hz to 19500 Hz)
      6 = [DT] Normal (3,72 Bytes/s - 1125 Hz to 2625 Hz)
      7 = [DT] Fast (5,59 Bytes/s - 1125 Hz to 2625 Hz)
      8 = [DT] Fastest (11,17 Bytes/s - 1125 Hz to 2625 Hz)
  ```

  ```bash
  $> pip install gg-transfer
  ```

  On PyPi, `ggwave-wheels` is now required, altough it provides the very same functions of the original `ggwave` package.
  This is due to some glitches in the original `ggwave` install process under python `>=3.11`. `ggwave-wheels` provides
  some pre-compiled wheels for `linux x86_64`, `windows x86_64` and `macOS` platforms.

  ```bash
  $> git clone https://github.com/matteotenca/gg-transfer.git
  $> cd gg-transfer
  $> pip install --user -e .
  ```

  ```
  usage: gg-transfer send [-h] [-i <inputfile>] [-p {0,1,2,3,4,5,6,7,8}] [-V] [-f]
  Command line utility to send/receive files/strings via ggwave library (FSK).
  optional arguments:
    -h, --help            show this help message and exit
    -i <inputfile>, --input <inputfile>
                          input file (use '-' for stdin).
    -p {0,1,2,3,4,5,6,7,8}, --protocol {0,1,2,3,4,5,6,7,8}
                          protocol, 0 to 8 (defaults to 0)
                          0 = Normal (11,17 Bytes/s - 1875 Hz to 6375 Hz)
                          1 = Fast (16,76 Bytes/s - 1875 Hz to 6375 Hz)
                          2 = Fastest (33,52 Bytes/s 1875 Hz to 6375 Hz)
                          3 = [U] Normal (11,17 Bytes/s - 15000 Hz to 19500 Hz)
                          4 = [U] Fast (16,76 Bytes/s - 15000 Hz to 19500 Hz)
                          5 = [U] Fastest (33,52 Bytes/s - 15000 Hz to 19500 Hz)
                          6 = [DT] Normal (3,72 Bytes/s - 1125 Hz to 2625 Hz)
                          7 = [DT] Fast (5,59 Bytes/s - 1125 Hz to 2625 Hz)
                          8 = [DT] Fastest (11,17 Bytes/s - 1125 Hz to 2625 Hz)
    -V, --version         print version number.
    -f, --file-transfer   decode data from Base64 and use file transfer mode.
  ```
  ```
  usage: gg-transfer receive [-h] [-o <outputfile>] [-w] [-n <pieces>] [-V] [-f]
  Command line utility to send/receive files/strings via ggwave library (FSK).
  optional arguments:
    -h, --help            show this help message and exit
    -o <outputfile>, --output <outputfile>
                          output file (use '-' for stdout).
    -w, --overwrite       overwrite output file if it exists.
    -n <pieces>, --tot-pieces <pieces>
                          receive this number of pieces and exit. Minimum is 1, default no limit.
    -V, --version         print version number.
    -f, --file-transfer   decode data from Base64 and use file transfer mode.
  ```


  ```bash
  $> echo "Hello world" | gg-transfer send --protocol 2
  Sending data, length: 16
  Piece 1/1 16 B
  Time taken to encode waveform: 1.2990546226501465
  Speed (payload only): 12.316649139324932 B/s
  $>
  ```

  ```bash
  $> gg-transfer receive
  Listening ... Press Ctrl+C to stop
  Hello world
  [...]
  ```


  ```bash
  $> gg-transfer send --protocol 2 --input somefile.bin --file-transfer
  Sending header, length: 71
  Pieces: 2
  Sending data, length: 176
  Piece 2/2 176 B
  Time taken to encode waveform: 6.816471338272095
  Speed (size of encoded payload + CRC): 23.47255523567687 B/s
  Speed (payload only): 17.311009486311693 B/s
  $>
  ```

  ```bash
  $> gg-transfer.exe receive --output /tmp/out.bin --file-transfer
  Listening ... Press Ctrl+C to stop
  Got header - Filename: .gitignore, Size: 118, CRC32: bec88992, Total pieces: 2
  Piece 2/2 176 B
  File received, CRC correct!
  ```


  ```python
  import ggtransfer
  s = ggtransfer.Sender(protocol=2)
  s.send("1234567890" * 15)
  ```

  ```python
  import ggtransfer
  r = ggtransfer.Receiver(file_transfer=False)
  rr = r.receive()
  ```

  You can contact me from my GitHub page at [https://github.com/matteotenca/gg-transfer](https://github.com/matteotenca/gg-transfer)


pkgId: 5a7a37fb83bb6be82811f69f60a4d944ce2e63f7f9ae226c46786b1bb9000b51
name: python-gguf-help
arch: noarch
version: 0.13.0
epoch: 0
release: 1
summary: Development documents and examples for gguf
url: https://ggml.ai
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gguf-0.13.0-1.src.rpm
location_href: Packages/python-gguf-help-0.13.0-1.noarch.rpm
checksum_type: sha256
description:
  This is a Python package for writing binary files in the [GGUF](https://github.com/ggerganov/ggml/pull/302)
  (GGML Universal File) format.

  See [convert_hf_to_gguf.py](https://github.com/ggerganov/llama.cpp/blob/master/convert_hf_to_gguf.py)
  as an example for its usage.


  ```sh
  pip install gguf
  ```



  [examples/writer.py](https://github.com/ggerganov/llama.cpp/blob/master/gguf-py/examples/writer.py) — Generates `example.gguf` in the current directory to demonstrate generating a GGUF file. Note that this file cannot be used as a model.

  [scripts/gguf_dump.py](https://github.com/ggerganov/llama.cpp/blob/master/gguf-py/scripts/gguf_dump.py) — Dumps a GGUF file's metadata to the console.

  [scripts/gguf_set_metadata.py](https://github.com/ggerganov/llama.cpp/blob/master/gguf-py/scripts/gguf_set_metadata.py) — Allows changing simple metadata values in a GGUF file by key.

  [scripts/gguf_convert_endian.py](https://github.com/ggerganov/llama.cpp/blob/master/gguf-py/scripts/gguf_convert_endian.py) — Allows converting the endianness of GGUF files.

  [scripts/gguf_new_metadata.py](https://github.com/ggerganov/llama.cpp/blob/master/gguf-py/scripts/gguf_new_metadata.py) — Copies a GGUF file with added/modified/removed metadata values.


  Maintainers who participate in development of this package are advised to install it in editable mode:

  ```sh
  cd /path/to/llama.cpp/gguf-py

  pip install --editable .
  ```

  **Note**: This may require to upgrade your Pip installation, with a message saying that editable installation currently requires `setup.py`.
  In this case, upgrade Pip to the latest:

  ```sh
  pip install --upgrade pip
  ```



  There's a GitHub workflow to make a release automatically upon creation of tags in a specified format.

  1. Bump the version in `pyproject.toml`.
  2. Create a tag named `gguf-vx.x.x` where `x.x.x` is the semantic version number.

  ```sh
  git tag -a gguf-v1.0.0 -m "Version 1.0 release"
  ```

  3. Push the tags.

  ```sh
  git push origin --tags
  ```


  If you want to publish the package manually for any reason, you need to have `twine` and `build` installed:

  ```sh
  pip install build twine
  ```

  Then, follow these steps to release a new version:

  1. Bump the version in `pyproject.toml`.
  2. Build the package:

  ```sh
  python -m build
  ```

  3. Upload the generated distribution archives:

  ```sh
  python -m twine upload dist/*
  ```



  From root of this repository you can run this command to run all the unit tests

  ```bash
  python -m unittest discover ./gguf-py -v
  ```


  - [ ] Include conversion scripts as command line entry points in this package.


pkgId: 2b1d93a43af6204230fe223e9727292a651b48f5e349ed268dfea1aad6c92618
name: python-ghexplain-help
arch: noarch
version: 0.0.3
epoch: 0
release: 1
summary: Development documents and examples for ghexplain
url: https://github.com/Stell0/ghexplain
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-ghexplain-0.0.3-1.src.rpm
location_href: Packages/python-ghexplain-help-0.0.3-1.noarch.rpm
checksum_type: sha256
description:
  A Python library that provides AI-powered explanations for GitHub issues using LangChain.



  ```bash
  pip install ghexplain
  ```





  ```python
  import ghexplain


  summary = ghexplain.issue("https://github.com/owner/repo/issues/123")


  summary_es = ghexplain.issue("https://github.com/owner/repo/issues/123", language="spanish")
  ```



  The package provides a CLI tool that can be used directly from your terminal:

  ```bash

  export GITHUB_TOKEN=$(gh auth token)


  ghexplain https://github.com/owner/repo/issues/123


  ghexplain https://github.com/owner/repo/issues/123 -l spanish


  ghexplain --help
  ```

  You can also use it with python -m:
  ```bash
  python -m ghexplain.cli https://github.com/owner/repo/issues/123
  ```


pkgId: 85f40a681794a2b271bb0da941bd45531eb889f8b4e486ec394fb0f08e2e3318
name: python-giftless-help
arch: noarch
version: 0.6.2
epoch: 0
release: 1
summary: Development documents and examples for giftless
url: https://giftless.datopian.com
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-giftless-0.6.2-1.src.rpm
location_href: Packages/python-giftless-help-0.6.2-1.noarch.rpm
checksum_type: sha256
description:
  [![Build Status](https://travis-ci.org/datopian/giftless.svg?branch=master)](https://travis-ci.org/datopian/giftless)
  [![Maintainability](https://api.codeclimate.com/v1/badges/58f05c5b5842c8bbbdbb/maintainability)](https://codeclimate.com/github/datopian/giftless/maintainability)
  [![Test Coverage](https://api.codeclimate.com/v1/badges/58f05c5b5842c8bbbdbb/test_coverage)](https://codeclimate.com/github/datopian/giftless/test_coverage)
  Giftless is a Python implementation of a [Git LFS][1] Server. It is designed
  with flexibility in mind, to allow pluggable storage backends, transfer
  methods and authentication methods.
  Giftless supports the *basic* Git LFS transfer mode with the following
  storage backends:
  * Local storage
  * [Google Cloud Storage](https://cloud.google.com/storage)
  * [Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/)
    with direct-to-cloud or streamed transfers
  * [Amazon S3 Storage](https://aws.amazon.com/s3/)
  In addition, Giftless implements a custom transfer mode called `multipart-basic`,
  which is designed to take advantage of many vendors' multipart upload
  capabilities. It requires a specialized Git LFS client to use, and is currently
  not supported by standard Git LFS.
  See the [giftless-client](https://github.com/datopian/giftless-client) project
  for a compatible Python Git LFS client.
  Additional transfer modes and storage backends could easily be added and
  configured.
  [1]: https://git-lfs.github.com/

rpm_license:
  Copyright 2020-2024 Datopian (Viderum, Inc.)  Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:  The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


pkgId: 7c1d8000d646a285f4dc6d85d2029bba039cf57824f3d2d0b1b49cdd29ae41fe
name: python-gimie-help
arch: noarch
version: 0.7.2
epoch: 0
release: 1
summary: Development documents and examples for gimie
url: https://github.com/sdsc-ordes/gimie
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gimie-0.7.2-1.src.rpm
location_href: Packages/python-gimie-help-0.7.2-1.noarch.rpm
checksum_type: sha256
description:
  Using Gimie: easy peasy, it's a 3 step process.

  To install the stable version on PyPI:
  ```shell
  pip install gimie
  ```
  To install the dev version from github:
  ```shell
  pip install git+https://github.com/sdsc-ordes/gimie.git@main#egg=gimie
  ```
  Gimie is also available as a docker container hosted on the [Github container registry](https://github.com/sdsc-ordes/gimie/pkgs/container/gimie):
  ```shell
  docker pull ghcr.io/sdsc-ordes/gimie:latest

  docker run -e GITHUB_TOKEN=$GITHUB_TOKEN ghcr.io/sdsc-ordes/gimie:latest gimie data <repo>
  ```

  In order to access the github api, you need to provide a github token with the `read:org` scope.

  New to access tokens? Or don't know how to get your Github / Gitlab token ?
  Have no fear, see
  [here for Github tokens](https://docs.github.com/en/enterprise-server@3.4/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) and [here for Gitlab tokens](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html).
  (Note: tokens are as precious as passwords! Treat them as such.)

  Gimie will use your access tokens to gather information for you. If you want info about a Github repo, Gimie needs your Github token; if you want info about a Gitlab Project then Gimie needs your Gitlab token.
  Add your tokens one by one in your terminal:
  your Github token:
  ```bash
  export GITHUB_TOKEN=
  ```
  and/or your Gitlab token:
  ```bash
  export GITLAB_TOKEN=
  ```


  ```shell
  gimie data https://github.com/numpy/numpy
  ```
  (want a Gitlab project instead? Just replace the URL in the command line)

  ```python
  from gimie.project import Project
  proj = Project("https://github.com/numpy/numpy")

  g = proj.extract()

  g_in_ttl = g.serialize(format='ttl')
  print(g_in_ttl)
  ```
  For more advanced use see [the documentation](https://sdsc-ordes.github.io/gimie/intro/usage_python.html).

  The default output is [Turtle](https://www.w3.org/TR/turtle/), a textual syntax for [RDF](https://en.wikipedia.org/wiki/Resource_Description_Framework) data model. We follow the schema recommended by [codemeta](https://codemeta.github.io/).
  Supported formats are turtle, json-ld and n-triples (by specifying the `--format` argument in your call i.e. `gimie data https://github.com/numpy/numpy --format 'ttl'`).


pkgId: 84a8e84fe5fe3d3b871dc7c367d701f17d0f9c67add2185880bc49da05053273
name: python-ginkgo-ai-client-help
arch: noarch
version: 0.4.0
epoch: 0
release: 1
summary: Development documents and examples for ginkgo-ai-client
url: https://pypi.org/project/ginkgo-ai-client/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-ginkgo-ai-client-0.4.0-1.src.rpm
location_href: Packages/python-ginkgo-ai-client-help-0.4.0-1.noarch.rpm
checksum_type: sha256
description:
  **Work in progress: this repo was just made public and we are still working on integration**

  A python client for [Ginkgo's AI model API](https://models.ginkgobioworks.ai/), to run inference on public and Ginkgo-proprietary models.
  Learn more in the [Model API announcement](https://www.ginkgobioworks.com/2024/09/17/ginkgo-model-api-ai-research/).



  Register at https://models.ginkgobioworks.ai/ to get credits and an API KEY (of the form `xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx`).
  Store the API KEY in the `GINKGOAI_API_KEY` environment variable.



  Install the python client with pip:

  ```bash
  pip install ginkgo-ai-client
  ```



  **Note: This is an alpha version of the client and its interface may vary in the future.**

  **Example : masked inference with Ginkgo's AA0 model**

  The client requires an API key (and defaults to `os.environ.get("GINKGOAI_API_KEY")` if none is explicitly provided)

  ```python
  from ginkgo_ai_client import GinkgoAIClient, MaskedInferenceQuery

  client = GinkgoAIClient()
  model = "ginkgo-aa0-650M"



  query = MaskedInferenceQuery(sequence="MPK<mask><mask>RRL", model=model)
  prediction = client.send_request(query)




  sequences = ["MPK<mask><mask>RRL", "M<mask>RL", "MLLM<mask><mask>R"]
  queries = [MaskedInferenceQuery(sequence=seq, model=model) for seq in sequences]
  predictions = client.send_batch_request(queries)

  ```

  Changing the `model` parameter to `esm2-650M` or `esm2-3b` in this example will perform
  masked inference with the ESM2 model.

  **Example : embedding computation with Ginkgo's 3'UTR language model**

  ```python
  from ginkgo_ai_client import GinkgoAIClient, MeanEmbeddingQuery

  client = GinkgoAIClient()
  model = "ginkgo-maskedlm-3utr-v1"



  query = MeanEmbeddingQuery(sequence="ATTGCG", model=model)
  prediction = client.send_request(query)




  sequences = ["ATTGCG", "CAATGC", "GCGCACATGT"]
  queries = [MeanEmbeddingQuery(sequence=seq, model=model) for seq in sequences]
  predictions = client.send_batch_request(queries)

  ```



  See the [example folder](examples/) and [reference docs](https://ginkgobioworks.github.io/ginkgo-ai-client/) for more details on usage and parameters.

  | Model | Description                                 | Reference                                                                                    | Supported queries            | Versions |
  | ----- | ------------------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------- | -------- |
  | ESM2  | Large Protein language model from Meta      | [Github](https://github.com/facebookresearch/esm?tab=readme-ov-file#esmfold)                 | Embeddings, masked inference | 3B, 650M |
  | AA0   | Ginkgo's proprietary protein language model | [Announcement](https://www.ginkgobioworks.com/2024/09/17/aa-0-protein-llm-technical-review/) | Embeddings, masked inference | 650M     |
  | 3UTR  | Ginkgo's proprietary 3'UTR language model   | [Preprint](https://www.biorxiv.org/content/10.1101/2024.10.07.616676v1)                      | Embeddings, masked inference | v1       |



  This project is licensed under the MIT License. See the `LICENSE` file for details.



  Make sure the changelog is up to date and the top section reads `Unreleased`. Increment the version with the `bumpversion` workflow in Actions - it will update the version everywhere in the repo, create a tag, and trigger a Github release. If all looks good, publish to PyPI via the `publish` workflow in Actions.


pkgId: bbceaaae7af1432ba293529fd415b086f4a16c40b9e6e24a9580cc4656813a19
name: python-ginput-help
arch: noarch
version: 1.3.1
epoch: 0
release: 1
summary: Development documents and examples for ginput
url: https://pypi.org/project/ginput/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-ginput-1.3.1-1.src.rpm
location_href: Packages/python-ginput-help-1.3.1-1.noarch.rpm
checksum_type: sha256
description:
  [![Documentation status](https://readthedocs.org/projects/ginput/badge/?version=latest)](https://ginput.readthedocs.io/en/latest/?badge=latest)



  Copyright (c) 2022, by the California Institute of Technology. ALL RIGHTS RESERVED. United States Government Sponsorship acknowledged. Any commercial use must be negotiated with the Office of Technology Transfer at the California Institute of Technology.

  This software may be subject to U.S. export control laws. By accepting this software, the user agrees to comply with all applicable U.S. export laws and regulations. User has the responsibility to obtain export licenses, or other export authority as may be required before exporting such information to foreign countries or providing access to foreign persons.

  Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  * Neither the name of Caltech nor its operating division, the Jet Propulsion Laboratory, nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.



  * Make sure you have a Python installation with the `conda` package manager
    on your system. We currently recommend [miniforge](https://github.com/conda-forge/miniforge).
  * Run `make install`
  * Run `./run_ginput.py --help` to see available subcommands
  * For more detailed help, try `man ginput` after running `make install`.
    (If that doesn't work, try `man man/build/man/ginput.1` from this
    directory or add `man/build/man/` to your `MANPATH`).

  For more install options, run `make help`.



  To check whether your installation is working, there are example .mod, .vmr, .map,
  and .map.nc files in `ginput/testing/test_input_data` that have been generated from
  both GEOS-FPIT and GEOS-FP. While TCCON uses GEOS-FPIT, it requires a data subscription,
  so you may prefer to use GEOS-FP.

  To verify you have installed and are using `ginput` correctly, we recommend you generate
  at least the .mod and .vmr files for Lamont (site code "oc") on 1 Jan 2018 and compare
  against the pregenerated test files. Differences should be less than ~1%.

  If you have GEOS FP-IT files available on your system, the script
  `ginput/testing/test_input_data/geosfp-it/link_geos_fpit_files.sh` will help link them
  to the correct location in this repo to run the automatic test case. `cd` to
  `ginput/testing/test_input_data/geosfp-it/` and run `./link_geos_fpit_files.sh --help`
  to see its usage. This requires the following files:

  * The 8 model level assimilated quantity files for 2018-01-01 (`GEOS.fpit.asm.inst3_3d_asm_Nv.GEOS5124.20180101*.nc4`)
  * The 8 2D assimilated quantity files for 2018-01-01 (`GEOS.fpit.asm.inst3_2d_asm_Nx.GEOS5124.20180101*.nc4`)
  * The 8 model level chemistry files for 2018-01-01 (`GEOS.fpit.asm.inst3_3d_chm_Nv.GEOS5124.20180101*.nc4`)

  To run the test, the easiest way is to activate the conda environment that `ginput` was installed
  in (`ginput-auto-default` if installed with `make install`) and run `make test`. This will take
  several minutes to run. If tests fail because the output .mod/.vmr/.map files do not match the expected,
  plots will be generated in `ginput/testing/plots` for you to inspect the differences and verify that
  they are reasonable.



  Man pages are created in `man/build/man/` during installation and can be accessed with e.g. `man man/build/man/ginput.1`.
  These may also be added to your MANPATH so that e.g. `man ginput` works, but this is system dependent. Full documentation
  is provided at https://ginput.readthedocs.io/en/latest/.

  Some additional documentation is provided on the TCCON wiki:

  * [Running ginput](https://tccon-wiki.caltech.edu/Main/UsingGinput)
  * [Code structure](https://tccon-wiki.caltech.edu/Main/GinputCodeStructure)

  These will be folded into the readthedocs instance in the future.



  Ginput is licensed under the Apache license as of 8 Sept 2022.
  Prior to this date, it was licensed under the LGPL license.
  If you download this software after 8 Sept 2022, you agree to abide by the terms of the
  Apache license.
  The full legal terms are contained in LICENSE.txt file. For a short summary, please see
  [here](https://choosealicense.com/licenses/apache-2.0/#). If you have any questions about
  use, please contact us (contact information is below).

  In addition to the Apache license, you should cite the ginput paper in any publications
  resulting from the use of ginput. (At time of release, the manuscript is still in preparation,
  so contact us for the citation.) Please also consider contacting us to let us know you are
  using ginput!



  Only Python 3 is supported. Python 2 reached end-of-life on 1 Jan 2020.
  We also require that the `conda` package manager provided with the Anaconda
  Python distribution be installed, and so only officially support Anaconda or
  Miniconda Python.

  If you have Anaconda or Miniconda based on Python 2 installed, that should work,
  as ginput is configured to create a Python 3 environment for itself on install.
  This also ensures that it's dependencies do not conflict with your existing
  setup.



  For assistance with `ginput`, contact [Josh Laughner](https://science.jpl.nasa.gov/people/joshua-laughner/).


pkgId: d68180b822cbd51f16d6a9f53db96c88335ea8d63376b1c349b6dcd0b48c189a
name: python-giquant-help
arch: noarch
version: 2024.0.3
epoch: 0
release: 1
summary: Development documents and examples for giquant
url: https://pypi.org/project/giquant/
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-giquant-2024.0.3-1.src.rpm
location_href: Packages/python-giquant-help-2024.0.3-1.noarch.rpm
checksum_type: sha256
description:
  This Python package contain various tools for Quantative Finance and Trading.
  It should be considered an alpha version but feel free to try it out!

  Install from PyPi with: `python3 -m pip install giquant`




  `giquiant.tsl` is a DSL (domain specific language) for manipulation of time series.

  Show the help with: `python3 -m giquant.tsl.expr --help`




  The trade subpackage has some tools related to trading.

  Show the help with:

  * `python3 -m giquant.trade.dwnl --help`
  * `python3 -m giquant.trade.cl --help`
  * `python3 -m giquant.trade.cc --help`

rpm_license:
  ISC License  Copyright (c) 2024, Jonas Colmsjö  Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.  THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.


pkgId: 70d46db38100942485e9857029a4a0484e4d0d630023da0c5e575cc7af8b497d
name: python-girder-client-help
arch: noarch
version: 3.2.6
epoch: 0
release: 1
summary: Development documents and examples for girder-client
url: http://girder.readthedocs.org/en/latest/python-client.html
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-girder-client-3.2.6-1.src.rpm
location_href: Packages/python-girder-client-help-3.2.6-1.noarch.rpm
checksum_type: sha256
description:
  This is a set of python libraries and a command-line tool that can be used to
  interact with the REST API of a `Girder <http://girder.readthedocs.org>`_ server.
  Documentation for the client can be found at http://girder.readthedocs.org/en/latest/python-client.html.


pkgId: 4751e3f3ff9e8db41c4a3a40571d0a035783c67cc848c9e8b9ad8c52087b5672
name: python-girder-help
arch: noarch
version: 3.2.6
epoch: 0
release: 1
summary: Development documents and examples for girder
url: https://girder.readthedocs.org
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-girder-3.2.6-1.src.rpm
location_href: Packages/python-girder-help-3.2.6-1.noarch.rpm
checksum_type: sha256
description:
  **Data Management Platform**
  Girder is a free and open source web-based data management platform developed by
  `Kitware <https://kitware.com>`_ as part of the `Resonant <http://resonant.kitware.com>`_
  data and analytics ecosystem.
  |kitware-logo|
  Documentation of the Girder platform can be found at
  https://girder.readthedocs.io.
  For questions, comments, or to get in touch with the maintainers, head to our `Discourse forum <https://discourse.girder.org>`_.
  We'd love for you to `contribute to Girder <CONTRIBUTING.rst>`_.


pkgId: 8cc7e2e13e002b070a8ff574cf5dc62030a361df89c4a2eaa8eaf6142a69141d
name: python-girder-large-image-annotation-help
arch: noarch
version: 1.30.5
epoch: 0
release: 1
summary: Development documents and examples for girder-large-image-annotation
url: https://github.com/girder/large_image
rpm_license: Apache Software License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-girder-large-image-annotation-1.30.5-1.src.rpm
location_href: Packages/python-girder-large-image-annotation-help-1.30.5-1.noarch.rpm
checksum_type: sha256
description:
  A Girder plugin to store and display annotations on large, multiresolution images.

  See the large-image package for more details.


pkgId: ef7a08597a0252ed324edaf93bff9547be6d26641a10934d4e226bc6e06d80ec
name: python-girder-large-image-help
arch: noarch
version: 1.30.5
epoch: 0
release: 1
summary: Development documents and examples for girder-large-image
url: https://github.com/girder/large_image
rpm_license: Apache Software License 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-girder-large-image-1.30.5-1.src.rpm
location_href: Packages/python-girder-large-image-help-1.30.5-1.noarch.rpm
checksum_type: sha256
description:
  A Girder plugin to work with large, multiresolution images.

  See the large-image package for more details.


pkgId: 09f59d77dcda32c7cecdd6a272254d8fe041ccc70afb40e394175d98972f4c13
name: python-gisweb-jppa-help
arch: noarch
version: 0.2.1
epoch: 0
release: 1
summary: Development documents and examples for gisweb-jppa
url: https://pypi.org/project/gisweb-jppa/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gisweb-jppa-0.2.1-1.src.rpm
location_href: Packages/python-gisweb-jppa-help-0.2.1-1.noarch.rpm
checksum_type: sha256
description:
  This is a simple example package. You can use
  [Github-flavored Markdown](https://guides.github.com/features/mastering-markdown/)
  to write your content.

  poetry update
  poetry build
  poetry publish

  casini venv
  per attivare quello giusto:
  source $(poetry env info --path)/bin/activate

  poetry env info -p
  rm -rf `poetry env info -p`
  poetry env use python


pkgId: aa4720715a16f1e3160f1f5142e6151f6744bfcb61a557607ea9d171977f7b9a
name: python-git-batch-help
arch: noarch
version: 4.0.2
epoch: 0
release: 1
summary: Development documents and examples for git-batch
url: https://github.com/thegeeklab/git-batch/
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-git-batch-4.0.2-1.src.rpm
location_href: Packages/python-git-batch-help-4.0.2-1.noarch.rpm
checksum_type: sha256
description:
  Automate cloning a single branch from a list of repositories

  [![Build Status](https://ci.thegeeklab.de/api/badges/thegeeklab/git-batch/status.svg)](https://ci.thegeeklab.de/repos/thegeeklab/git-batch)
  [![Docker Hub](https://img.shields.io/badge/dockerhub-latest-blue.svg?logo=docker&logoColor=white)](https://hub.docker.com/r/thegeeklab/git-batch)
  [![Quay.io](https://img.shields.io/badge/quay-latest-blue.svg?logo=docker&logoColor=white)](https://quay.io/repository/thegeeklab/git-batch)
  [![Python Version](https://img.shields.io/pypi/pyversions/git-batch.svg)](https://pypi.org/project/git-batch/)
  [![PyPi Status](https://img.shields.io/pypi/status/git-batch.svg)](https://pypi.org/project/git-batch/)
  [![PyPi Release](https://img.shields.io/pypi/v/git-batch.svg)](https://pypi.org/project/git-batch/)
  [![GitHub contributors](https://img.shields.io/github/contributors/thegeeklab/git-batch)](https://github.com/thegeeklab/git-batch/graphs/contributors)
  [![Source: GitHub](https://img.shields.io/badge/source-github-blue.svg?logo=github&logoColor=white)](https://github.com/thegeeklab/git-batch)
  [![License: MIT](https://img.shields.io/github/license/thegeeklab/git-batch)](https://github.com/thegeeklab/git-batch/blob/main/LICENSE)

  Simple tool to automate cloning a single branch from a list of repositories.



  Special thanks to all [contributors](https://github.com/thegeeklab/git-batch/graphs/contributors). If you would like to contribute,
  please see the [instructions](https://github.com/thegeeklab/git-batch/blob/main/CONTRIBUTING.md).



  This project is licensed under the MIT License - see the [LICENSE](https://github.com/thegeeklab/git-batch/blob/main/LICENSE) file for details.


pkgId: 4fac5a9397318d5f69054a9e82e32605fd82260aef7837287e4ca683b0d596b2
name: python-git-bob-help
arch: noarch
version: 0.15.2
epoch: 0
release: 1
summary: Development documents and examples for git-bob
url: https://github.com/haesleinhuepf/git-bob
rpm_license: BSD-3-Clause
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-git-bob-0.15.2-1.src.rpm
location_href: Packages/python-git-bob-help-0.15.2-1.noarch.rpm
checksum_type: sha256
description:
  [![PyPI](https://img.shields.io/pypi/v/git-bob.svg?color=green)](https://pypi.org/project/git-bob)
  [![DOI](https://zenodo.org/badge/831841421.svg)](https://doi.org/10.5281/zenodo.13970719)
  [![License](https://img.shields.io/pypi/l/git-bob.svg?color=green)](https://github.com/haesleinhuepf/git-bob/raw/main/LICENSE)
  <!--[![PyPI - Downloads](https://img.shields.io/pypi/dm/git-bob)](https://pypistats.org/packages/git-bob)-->

  git-bob uses AI to solve GitHub issues and review pull requests. It runs inside the GitHub CI, no need to install anything on your computer.
  Read more in the [preprint](https://doi.org/10.5281/zenodo.13928832).

  ![banner](https://github.com/haesleinhuepf/git-bob/raw/main/docs/images/banner2.png)

  Under the hood it uses [Anthropic's Claude](https://www.anthropic.com/api) or [OpenAI's chatGPT](https://openai.com/blog/openai-api) or [Google's Gemini](https://blog.google/technology/ai/google-gemini-ai/) to understand the text and
  [pygithub](https://github.com/PyGithub/PyGithub) to interact with the issues and pull requests. As its discussions are conserved, you can document how things were done using AI and
  others can learn how to prompt for the things you did. For example, the pair-plot discussion above is [available online](https://github.com/haesleinhuepf/git-bob-playground/issues/48).



  `git-bob` is a research project aiming at streamlining GitHub interaction in software development projects. Under the hood it uses
  artificial intelligence / large language models to generate text and code fulfilling the user's requests.
  Users are responsible to verify the generated code according to good scientific practice.

  When using `git-bob` you configure it to use an API key to access the AI models.
  You have to pay for the usage and must be careful in using the software.
  Do not use this technology if you are not aware of the costs and consequences.

  > [!CAUTION]
  > When using the Anthropic, OpenAI, Google Gemini, Mistral or any other endpoint via git-bob, you are bound to the terms of service
  > of the respective companies or organizations.
  > The GitHub issues, pull requests and messages you enter are transferred to their servers and may be processed and stored there.
  > Make sure to not submit any sensitive, confidential or personal data. Also using these services may cost money.



  There is a detailed [tutorial](https://github.com/haesleinhuepf/git-bob/blob/main/docs/installation-tutorial.md) on how to install git-bob as GitHub action to your repository. In very short, to use git-bob in your GitHub repository, you need to
  * Copy the [git-bob](https://github.com/haesleinhuepf/git-bob/blob/main/.github/workflows/git-bob.yml) GitHub workflow in folder `.github/workflows/` to your repository.
    * Make sure to replace `pip install -e .` with a specific git-bob version such as `pip install git-bob==0.12.0`.
    * Configure the LLM you want to use in the workflow files by specifying the `GIT_BOB_LLM_NAME` environment variable. These were tested:
      * `claude-3-5-sonnet-20241022`
      * `gpt-4o-2024-08-06`
      * `github_models:gpt-4o`
      * `github_models:meta-llama-3.1-405b-instruct`
      * `gemini-1.5-pro-002`
      * `mistral-large-2411` (uses `pixtral-12b-2409` for vision tasks)
    * configure a GitHub secret called `OPENAI_API_KEY` or `ANTHROPIC_API_KEY` or `GH_MODELS_API_KEY` or `GOOGLE_API_KEY` or `MISTRAL_API_KEY` or `KISSKI_API_KEY` or `BLABBLADOR_API_KEY` with the corresponding key from the LLM provider depending on the above configured LLM. You can get these keys here:
      * [OpenAI (gpt)](https://openai.com/blog/openai-api)
      * [Anthropic (claude)](https://www.anthropic.com/api)
      * [GitHub Models Marketplace](https://github.com/marketplace/models)
      * [Google AI](https://ai.google.dev/gemini-api/docs/api-key)
      * [Mistral](https://console.mistral.ai/api-keys/)
      * [KISSKI](https://services.kisski.de/services/en/service/?service=2-02-llm-service.json)
      * [BLABLADOR](https://login.helmholtz.de/oauth2-as/oauth2-authz-web-entry)
    * configure GitHub actions to run the workflow on issues and pull requests. Also give write-access to the Workflow using the `GITHUB_TOKEN`.

  When using it in your repository, you can also set a custom system message, for example for:
  * [General Data Science / Python Programming](https://github.com/haesleinhuepf/git-bob-playground/blob/bf08b3526980e011f632c13f29ae65372aafa5c7/.github/workflows/git-bob.yml#L75)
  * [Bio-Image Analysis](https://github.com/haesleinhuepf/git-bob-bioimage-analysis-example/blob/main/.github/workflows/git-bob.yml#L75)
  * [Giving advice on a specific repository / library](https://github.com/haesleinhuepf/stackview/blob/afc662a71a39f298af9f183c06c3d37c95cc2015/.github/workflows/git-bob.yml#L58)
  * [Manuscript writing](https://github.com/haesleinhuepf/git-bob-manuscript/blob/49659f8a41854d4da696259e7c1316af2fc7c171/.github/workflows/comment-on-issue.yml#L49)

  Furthermore, to guide discussions, you may want to setup issue templates, e.g.
  * [General Python Programming Questions](https://github.com/haesleinhuepf/git-bob-playground/blob/main/.github/ISSUE_TEMPLATE/programming.md)
  * [Bio-Image Analysis](https://github.com/haesleinhuepf/git-bob-playground/blob/main/.github/ISSUE_TEMPLATE/bioimage_analysis.md)
  * [Statistics and Plotting](https://github.com/haesleinhuepf/git-bob-playground/blob/main/.github/ISSUE_TEMPLATE/statistics_plotting.md)



  Since version 0.10.1 git-bob has experimental support for [gitlab](https://gitlab.com). You find detailed instructions how to install it [here](https://github.com/haesleinhuepf/git-bob/blob/main/docs/installation-tutorial-gitlab.md).



  To trigger git-bob, you need to comment on an issue or pull request with the `comment` trigger word (or aliases `think about`, `review`, `respond`):

  ```
  git-bob comment
  ```

  If you want to ask git-bob for a review of a pull-request, you can use the `review` trigger word. Also make sure mention explictly what you want to be reviewed.

  ```
  git-bob review this PR. Check code quality and comments.
  ```

  After some back-and-forth discussion, you can also use the `solve` trigger word (or aliases `implement`, `apply`) make git-bob solve an issue and send a pull-request.
  This trigger can also be used to modify code in pull requests.

  ```
  git-bob solve
  ```

  You can ask git-bob to implement a solution for testing, without sending a pull-request, using the `try` trigger:
  ```
  git-bob try
  ```

  If you have multiple API-Key for different LLMs configured, you can specify the LLM in the command using the `ask <LLM-Name> to` trigger command:

  ```
  git-bob ask claude-3-5-sonnet-20241022 to solve this issue.
  ```

  If the issue is complex and should be split into sub-issues, you can use the following command:

  ```
  git-bob split
  ```

  If you have two GitHub secrets `TWINE_USERNAME` and `TWINE_PASSWORD` configured, you can also use the following command to publish a new version of your library to PyPI:

  ```
  git-bob deploy
  ```

  All trigger words can be combined with `please` and/or `,`, which will make no difference to calling git-bob without these words:

  ```
  git-bob, please ask gemini-1.5-pro-002 to solve this issue.
  ```



  Here's the recommended workflow for using git-bob:

  1. Create an issue describing the problem or task.
  2. Comment on the issue with `git-bob comment`, or `git-bob think about this` (an alias for `comment`) to trigger git-bob making a plan.
  3. Respond to git-bob with any clarifications or additional information it requests.
  4. Comment on the issue with `git-bob solve` or `git-bob implement this` (an alias for `solve`) to trigger git-bob.
  5. Wait for git-bob to create a pull request (PR) addressing the issue.
  6. Review the PR and comment on the PR or on the original issue if changes are needed.
  7. Wait for git-bob to create new PR or modifying the existing PR with the requested changes.
  8. Repeat steps 3-5 as necessary until the issue is resolved satisfactorily.



  A huge variety of use-cases for git-bob are thinkable. Here are some examples. Many serve purely demonstrative purposes.
  Some were parts of real scientific data analysis projects.

  * Question answering
    * [About specific Python libraries](https://github.com/haesleinhuepf/stackview/issues/79)
    * [The capital of France](https://github.com/haesleinhuepf/git-bob-playground/issues/24)
  * Translation
    * [Translating text in Jupyter notebooks in other Languages](https://github.com/haesleinhuepf/git-bob-playground/issues/118)
  * Bio-image Analysis
    * [Nuclei segmentation](https://github.com/haesleinhuepf/git-bob-playground/issues/13)
    * [Cell segmentation](https://github.com/haesleinhuepf/git-bob-playground/issues/42)
    * [Resizing images](https://github.com/NFDI4BIOIMAGE/training/issues/356)
  * Programming
    * [Caching](https://github.com/NFDI4BIOIMAGE/SlideInsight/issues/28)
  * Continuous Integration and Deployment
    * [Configuring Github workflows](https://github.com/haesleinhuepf/git-bob-playground/issues/146)
    * [Configuring a Jupyter Book](https://github.com/NFDI4BIOIMAGE/training/issues/381)
  * Data & Code Management
    * [Research Data Management & Folder Structures](https://github.com/haesleinhuepf/git-bob-playground/issues/45)
    * [Documenting source code](https://github.com/haesleinhuepf/git-bob/pull/29)
    * [Determining licenses of dependencies](https://github.com/haesleinhuepf/git-bob-playground/issues/101)
    * [Assisting scientific manuscript writing](https://github.com/haesleinhuepf/git-bob-manuscript/pull/9)
    * [Deleting files](https://github.com/haesleinhuepf/git-bob/issues/412)
    * [Converting tables to key-value pairs](https://github.com/haesleinhuepf/git-bob-playground/issues/103)
    * [Exporting Google Scholar profile as bibtex](https://github.com/haesleinhuepf/git-bob-playground/issues/114)
    * [Deciding for file formats: JSON versus YAML](https://github.com/haesleinhuepf/git-bob-playground/issues/117)
    * [Generating Galaxy workflows](https://github.com/haesleinhuepf/git-bob-playground/issues/123)
    * [Count citations of given DOIs](https://github.com/haesleinhuepf/git-bob-playground/issues/141)
  * Graphical User Interfaces
    * [Interactive drawing on an ipcanvas](https://github.com/haesleinhuepf/git-bob-playground/issues/121)
  * Statistics
    * [Filtering data and counting records](https://github.com/NFDI4BIOIMAGE/training/issues/299)
    * [Selecting ranges of columns](https://github.com/haesleinhuepf/git-bob-playground/issues/47)
    * [Summarizing data and plotting](https://github.com/NFDI4BIOIMAGE/training/issues/250)
  * Plotting
    * [Violing plots with simulated data](https://github.com/haesleinhuepf/git-bob-playground/issues/44)
    * [UMAPs with simulated data](https://github.com/haesleinhuepf/git-bob-playground/issues/41)
    * [Plotting a circle of triangles (in gitlab)](https://gitlab.com/haesleinhuepf/git-bob-gitlab-playground/-/issues/8)
    * [Pairplots with simulated data](https://github.com/haesleinhuepf/git-bob-playground/issues/48)
    * [Word clouds](https://github.com/haesleinhuepf/git-bob-playground/issues/76)
  * Science Communication
    * [Making slides for Deep Learning training](https://github.com/haesleinhuepf/git-bob-playground/issues/97)
    * [Making slides for Research Data Management training](https://github.com/haesleinhuepf/git-bob-playground/issues/96)
    * [Visualizing how Fourier-Transform works](https://github.com/haesleinhuepf/git-bob-playground/issues/22)
    * [Making Jupyter Notebooks for training](https://github.com/haesleinhuepf/git-bob-playground/issues/92)
    * [Making slides about text](https://github.com/haesleinhuepf/git-bob-playground/issues/98)
  * Fun
    * [Playing Tic-Tac-Toe](https://github.com/haesleinhuepf/git-bob-playground/issues/91)
    * [Story Telling for kids](https://github.com/haesleinhuepf/git-bob-playground/issues/82)
    * [PowerPoint Karaoke](https://github.com/haesleinhuepf/git-bob-playground/issues/99)
  * Things that did't work well
    * [How to use aider from python](https://github.com/haesleinhuepf/git-bob/issues/437#issuecomment-2539865080)
    * [How to use the atproto API](https://github.com/haesleinhuepf/git-bob-playground/issues/136)



  ```
  git clone https://github.com/haselinhuepf/git-bob.git
  cd git-bob
  ```



  You can also install git-bob locally and run it from the terminal.
  In this case, create a [GitHub token](https://github.com/settings/tokens) and store it in an environment variable named `GITHUB_API_KEY`.
  Also create an environment variable `GIT_BOB_LLM_NAME` with the name of the LLM you want to use, e.g. "gpt-4o-2024-05-13" or "claude-3-5-sonnet-20241022" or "github_models:gpt-4o".
  Then you can install git-bob using pip:

  ```bash
  pip install git-bob
  ```



  You can then use git-bob from the terminal on repositories you have read/write access to.
  It is recommended to call it from the root folder of the repository you want to interact with.

  ```bash
  git clone https://github.com/<organization>/<repository>
  cd <repository>
  git-bob <action> <organization>/<repository> <issue-number>
  ```

  Available actions:
  * `review-pull-request`
  * `comment-on-issue`
  * `solve-issue`
  * `split-issue`


  `git-bob` is a research project and has limitations. It serves as basis for discussion and further development. Once LLMs become better, `git-bob` will become better as well.

  At the moment, these limitations can be observed:
  * `git-bob` was tested for Python projects mostly. It seems to be able to process Java and C++ as well.
  * It can only execute code in Jupyter Notebooks.
  * It sometimes hallucinates, especially in code reviews. E.g. it [claimed](https://github.com/haesleinhuepf/git-bob/pull/70) to have tested code, which was certainly not true.
  * It cannot solve issues where changing long files is required, as the output of the LLMs is limited by a maximum number of tokens (e.g. 16k for `gpt-4o-2024-08-06`). When using OpenAI's models it combines output of multiple requests to a maximum file length about 64k tokens. It may then miss some spaces or a line break where responses were stitched.
    When using GitHub models, the maximum file length is 4k tokens. When using Anthropic's Claude, the maximum file length is 8k tokens.
  * When changing multiple files, it may introduce conflicts between the files, as it does not know about the changed contents of the other files.
  * It has only limited logic to control who is allowed to trigger it.
    If you are a repository member, you can trigger it.
    If others send a pull request, a repository member must allow the action to run manually.
  * `git-bob` is incompatible with locally running open-source/-weight LLMs.
    This might make sense when being executed locally only. In the GitHub-CI this might be impossible.
  * Recently tested `claude-3-5-sonnet-20241022`, `gpt-4o-2024-08-06`, `github_models:gpt-4o`, `github_models:meta-llama-3.1-405b-instruct` and `gemini-1.5-pro-002` produced useful results.
  * `git-bob` is not allowed to modify workflow files, because it also uses GitHub workflows.
  * As git-bob is installed as part of git-hub workflows, its [download statistics](https://pypistats.org/packages/git-bob) might be misleading. There are not as many people downloading it as the numer of downloads suggest.



  There are similar projects out there
  * [Claude Engineer](https://github.com/Doriandarko/claude-engineer)
  * [BioChatter](https://github.com/biocypher/biochatter)
  * [aider](https://github.com/paul-gauthier/aider)
  * [OpenDevin](https://github.com/OpenDevin/OpenDevin)
  * [Devika](https://github.com/stitionai/devika)
  * [GPT-Codemaster](https://github.com/dex3r/GPT-Codemaster)
  * [GitHub Copilot Workspace](https://githubnext.com/projects/copilot-workspace)
  * [agentless](https://github.com/OpenAutoCoder/Agentless)
  * [git-aid](https://github.com/Torantulino/git-aid)
  * [SWE-agent](https://github.com/princeton-nlp/SWE-agent)



  Feedback and contributions are welcome! Just open an issue and let's discuss before you send a pull request.
  A [human](https://haesleinhuepf.github.io) will respond and comment on your ideas!



  If you use git-bob, please cite it:
  ```
  @misc{haase_2024_13928832,
    author       = {Haase, Robert},
    title        = {{Towards Transparency and Knowledge Exchange in AI-
                     assisted Data Analysis Code Generation}},
    month        = oct,
    year         = 2024,
    publisher    = {Zenodo},
    doi          = {10.5281/zenodo.13928832},
    url          = {https://doi.org/10.5281/zenodo.13928832}
  }
  ```



  We acknowledge the financial support by the Federal Ministry of Education and Research of Germany and by Sächsische Staatsministerium für Wissenschaft, Kultur und Tourismus in the programme Center of Excellence for AI-research „Center for Scalable Data Analytics and Artificial Intelligence Dresden/Leipzig", project identification number: ScaDS.AI


pkgId: 39b8716e2e267100e60f8b6235b4f6d87205134699fffc278575b18196acfbaf
name: python-git-cola-help
arch: noarch
version: 4.10.1
epoch: 0
release: 1
summary: Development documents and examples for git-cola
url: https://pypi.org/project/git-cola/
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-git-cola-4.10.1-1.src.rpm
location_href: Packages/python-git-cola-help-4.10.1-1.noarch.rpm
checksum_type: sha256
description:
  Git Cola is a powerful Git GUI with a slick and intuitive user interface.

      git clone https://github.com/git-cola/git-cola.git

  [![License](https://img.shields.io/:license-GPL-green.svg)](LICENSE)
  [![Build status](https://github.com/git-cola/git-cola/actions/workflows/ci.yml/badge.svg?event=push)](https://github.com/git-cola/git-cola/actions/workflows/main.yml)
  [![OpenSSF Best Practices](https://bestpractices.coreinfrastructure.org/projects/251/badge)](https://bestpractices.coreinfrastructure.org/projects/251)
  [![pre-commit.ci](https://results.pre-commit.ci/badge/github/git-cola/git-cola/main.svg)](https://results.pre-commit.ci/latest/github/git-cola/git-cola/main)

  * [Screenshots](https://git-cola.github.io/screenshots.html)

  * [Downloads](https://git-cola.github.io/downloads.html)




  * [Keyboard shortcuts](https://git-cola.github.io/share/doc/git-cola/hotkeys.html)

  * [HTML documentation](https://git-cola.readthedocs.io/en/latest/)

  * [Git Cola documentation](docs/git-cola.rst)

  * [Git DAG documentation](docs/git-dag.rst)

  * [Contributing guidelines](CONTRIBUTING.md)






  * [Sphinx](http://sphinx-doc.org/) is used to generate the documentation.



  * [Git](https://git-scm.com/) 2.2.0 or newer.

  * [Python](https://python.org/) 3.6 or newer.

  * [QtPy](https://github.com/spyder-ide/qtpy) 2.0.0 or newer.

  Git Cola uses QtPy, so you can choose between PyQt6, PyQt5 and PySide2 by setting
  the `QT_API` environment variable to `pyqt6`, `pyqt5` or `pyside2` as desired.
  `qtpy` defaults to `pyqt5` and falls back to `pyqt6` and `pyside2` if `pyqt5`
  is not installed.

  Any of the following Python Qt libraries must be installed:

  * [PyQt5 / PyQt6](https://www.riverbankcomputing.com/software/pyqt/download5)
    5.9 or newer is required. Qt 6.2 or newer is also supported via QtPy.

  * [PySide2](https://github.com/PySide/PySide)
    5.12.0 or newer.




  Git Cola enables additional features when the following
  Python modules are installed.

  [Send2Trash](https://pypi.org/project/Send2Trash)
  enables cross-platform "Send to Trash" functionality.
  ([source](https://github.com/hsoft/send2trash))

  [notify2](https://pypi.org/project/notify2)
  enables delivery of desktop notifications.
  ([source](https://bitbucket.org/takluyver/pynotify2))

  [pyobjc](https://pypi.org/project/pyobjc)
  enables macOS-specific application themes on macOS.
  ([source](https://github.com/ronaldoussoren/pyobjc))




  There are several ways to install Git Cola but you do not need to "install" Git Cola
  in order to run it.

  Git Cola is designed to run directly from its source tree. Installation is optional.




  The recommended approach for running the latest Git Cola version is to install its
  PyQt dependencies using your distribution's package manager and then run
  `./bin/git-cola` directly from source.




  Git Cola works with either PyQt5 or PyQt6 because it uses the
  [qtpy](https://github.com/spyder-ide/qtpy) library for PyQt compatibility.



  Users on newer Debian/Ubuntu version can install a single package to run from source.

  ```bash
  sudo apt install python3-qtpy
  ```

  If you are on an older version that does not have `python3-qtpy` available then you can
  install the following packages directly.

  ```bash
  sudo apt install python3-pyqt5 python3-pyqt5.qtopengl python3-pyqt5.qtwebengine python3-pyqt5.qtsvg
  ```



  If you'd like to use Git Cola with the newer PyQt6 ecosystem then you can install these
  packages instead of PyQt5.

  ```bash
  sudo apt install python3-pyqt6 python3-pyqt6.qtsvg python3-pyqt6.qtwebengine
  ```

  At this point you should be able to launch `./bin/git-cola` from the source tree and
  there is nothing more to do.

  The further instructions below detail how to install Git Cola from PyPI or how to
  install it into a location separate from the source tree.




  Linux is it! Your distro has probably already packaged `git-cola`.
  If not, please file a bug against your distribution ;-)



  Available in the [AUR](https://aur.archlinux.org/packages/git-cola/).



      apt install git-cola



      dnf install git-cola



      emerge git-cola



      zypper install git-cola



  Available in [SlackBuilds.org](http://slackbuilds.org/result/?search=git-cola).



  [See here](https://packages.ubuntu.com/search?keywords=git-cola) for the
  versions that are available in Ubuntu's repositories.



      
      pkg install -r FreeBSD devel/git-cola

      
      cd /usr/ports/devel/git-cola && make clean install



  **IMPORTANT**: never run `pip install` or `garden install` outside of a
  Python virtualenv or as root!

  **IMPORTANT**: if you are on Linux distributions where PyQt6 or PyQt5 are available from
  your package manager then it is highly recommended to install those dependencies using
  your system's package manager. See the section above for details.

  One way to install the latest released version is to use `venv` (virtualenv) and `pip`.
  This installs [git-cola from pypi.org](https://pypi.org/project/git-cola/).

      python3 -m venv --system-site-packages env3
      ./env3/bin/pip install git-cola
      ./env3/bin/git-cola

  Add the `env3/bin` directory to your `PATH` or symlink to `bin/git-cola` from
  somewhere in your `PATH` such as `~/.local/bin/git-cola`, and you can launch
  Git Cola like any other built-in `git` command:

      git cola
      git dag




  If you don't have PyQt installed then the easiest way to get it is to use a Python
  virtualenv and install Git Cola into it in "editable" mode.

  This install method lets you upgrade Git Cola by running `git pull`.

      
      python3 -m venv --system-site-packages env3

      
      ./env3/bin/pip install --editable '.[extras,pyqt6]'

      
      source env3/bin/activate
      git cola

  If you add `env3/bin` (or symlink to `env3/bin/git-cola` ) somewhere in your `$PATH` then you can
  run `git cola` as if it were a builtin `git` command from outside of the virtualenv
  (e.g. after running "deactivate" or when opening a new shell).




  Running `garden -D prefix=$HOME/.local install` will install Git Cola in your
  `$HOME/.local` directory (`$HOME/.local/bin/git-cola`, `$HOME/.local/lib`, etc).

  This installation method assumes that the `qtpy` and `PyQt*` dependencies have
  been pre-installed.

  The Garden recipe also supports `DESTDIR` to support creating packages for Linux package
  managers:

      garden -D DESTDIR=/tmp/stage -D prefix=/usr/local install

  If you do not have `garden` available then `make` can be used instead.
  The `Makefile` supports staged installs using the conventional
  [DESTDIR](https://www.gnu.org/software/make/manual/html_node/DESTDIR.html) and
  [prefix](https://www.gnu.org/software/make/manual/html_node/Directory-Variables.html)
  variables.

      make DESTDIR=/tmp/stage prefix=/usr/local install




  For most end-users we recommend using either Homebrew or installing into
  a Python virtualenv as described above.

  You can install Git Cola from source using the same steps as above.



  An easy way to install Git Cola is to use [Homebrew](https://brew.sh/) .
  Use Homebrew to install the git-cola recipe:

      brew install git-cola

  If you install using Homebrew you can stop at this step.
  You don't need to clone the repo or anything.



  If you have all of the dependencies installed, either via `pip` or `brew` then
  you can build a shell `git-cola.app` app bundle wrapper for use in `/Applications`.

  If you'd like to build a `git-cola.app` bundle for `/Applications` run this command:

      garden macos/app

  You will need to periodically rebuild the app wrapper whenever Python is upgraded.



  Updating macOS can often break Homebrew-managed software.

  If you update macOS and Git Cola stops working then then you probably need to re-install
  Git Cola's dependencies.

  Re-installing from scratch using the instructions below can get things back in shape.

      brew update

      brew uninstall git-cola
      brew uninstall pyqt
      brew uninstall pyqt@5
      brew autoremove

      brew install git-cola




  IMPORTANT If you have a 64-bit machine, install the 64-bit versions only.
  Do not mix 32-bit and 64-bit versions.

  Download and install the following:

  * [Git for Windows](https://git-for-windows.github.io/)

  * [Git Cola](https://github.com/git-cola/git-cola/releases)

  Once these are installed you can run Git Cola from the Start menu.

  See "Windows (Continued)" below for more details.

  If you'd like to install Git Cola with
  [winget](https://github.com/microsoft/winget-cli) run the following command:

      winget install git-cola.git-cola

  As there is no dependency resolution yet you have to install Git as well with:

      winget install Git.Git



  Git Cola ships with an interactive rebase editor called `git-cola-sequence-editor`.
  `git-cola-sequence-editor` is used to reorder and choose commits when rebasing.
  Start an interactive rebase through the "Rebase" menu, or through the
  `git cola rebase` sub-command to use the `git-cola-sequence-editor`:

      git cola rebase @{upstream}

  `git-cola-sequence-editor` can be launched independently of git cola by telling
  `git rebase` to use it as its editor through the `GIT_SEQUENCE_EDITOR`
  environment variable:

      export GIT_SEQUENCE_EDITOR="$HOME/git-cola/bin/git-cola-sequence-editor"
      git rebase -i @{upstream}



  Shell completion scripts are available for bash and zsh.
  Each script contains instructions on how to install and activate the completions.

  * [bash completion script](contrib/git-cola-completion.bash)

  * [zsh completion script](contrib/_git-cola)




  The `git-cola` command exposes various sub-commands that allow you to quickly
  launch tools that are available from within the git-cola interface.
  For example, `git cola find` launches the file finder,
  and `git cola grep` launches the grep tool.

  See `git cola --help-commands` for the full list of commands.

      $ git cola --help-commands
      usage: git-cola [-h]

                      {cola,am,archive,branch,browse,config,
                       dag,diff,fetch,find,grep,merge,pull,push,
                       rebase,remote,search,stash,tag,version}
                      ...

      valid commands:
        {cola,am,archive,branch,browse,config,
         dag,diff,fetch,find,grep,merge,pull,push,
         rebase,remote,search,stash,tag,version}

          cola                start git-cola
          am                  apply patches using "git am"
          archive             save an archive
          branch              create a branch
          browse              browse repository
          config              edit configuration
          dag                 start git-dag
          diff                view diffs
          fetch               fetch remotes
          find                find files
          grep                grep source
          merge               merge branches
          pull                pull remote branches
          push                push remote branches
          rebase              interactive rebase
          remote              edit remotes
          search              search commits
          stash               stash and unstash changes
          tag                 create tags
          version             print the version



  [![Good First Issues](https://img.shields.io/github/issues/git-cola/git-cola/good%20first%20issue?style=flat&logo=github&logoColor=green&label=Good%20First%20issues)](https://github.com/git-cola/git-cola/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
  [![Help Wanted Issues](https://img.shields.io/github/issues/git-cola/git-cola/help%20wanted?style=flat&logo=github&logoColor=b545d1&label=%22Help%20Wanted%22%20issues)](https://github.com/git-cola/git-cola/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)
  [![Help Wanted PRs](https://img.shields.io/github/issues-pr/git-cola/git-cola/help%20wanted?style=flat&logo=github&logoColor=b545d1&label=%22Help%20Wanted%22%20PRs)](https://github.com/git-cola/git-cola/pulls?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)
  [![Open Issues](https://img.shields.io/github/issues/git-cola/git-cola?style=flat&logo=github&logoColor=red&label=Issues)](https://github.com/git-cola/git-cola/issues?q=is%3Aopen)

  If you already have Git Cola's dependencies installed then you can
  start `cola` as a Python module if you have the source code available.

      python -m cola
      python -m cola dag


  The following commands should be run during development:

      
      $ garden test

      
      $ garden check

      
      $ garden tox

  The test suite can be found in the [test](test) directory.

  Commits and pull requests are automatically tested for code quality
  using [GitHub Actions](https://github.com/git-cola/git-cola/actions/workflows/main.yml).

  Auto-format `cola/i18n/*.po` files before committing when updating translations:

      $ garden po

  When submitting patches, consult the
  [contributing guidelines](CONTRIBUTING.md).




  Git Cola installs its modules into the default Python site-packages directory
  (e.g. `lib/python3.7/site-packages`) using setuptools.

  While end-users can use `pip install git-cola` to install Git Cola, distribution
  packagers should use the `garden -D prefix=/usr install` process. Git Cola's Garden
  recipe wraps `pip install --prefix=<prefix>` to provide a packaging-friendly
  `garden install` target.






  Earlier versions of Git Cola may have shipped without `vcruntime140.dll`  and may
  not run on machines that are missing this DLL.

  To fix this, download the
  [Microsoft Visual C++ 2015 Redistributable](https://www.microsoft.com/en-us/download/details.aspx?id=52685)
  and install it

  Git Cola v4.0.0 and newer include this DLL and do not require this to be installed
  separately.



  In order to develop Git Cola on Windows you will need to install
  Python3 and pip.  Install PyQt5 using `pip install PyQt5`
  to make the PyQt5 bindings available to Python.

  Once these are installed you can use `python.exe` to run
  directly from the source tree.  For example, from a Git Bash terminal:

      /c/Python39/python.exe ./bin/git-cola



  If you have multiple versions of Python installed, the `contrib/win32/cola`
  launcher script might choose the newer version instead of the python
  that has PyQt installed.  In order to resolve this, you can set the
  `cola.pythonlocation` git configuration variable to tell cola where to
  find python.  For example:

      git config --global cola.pythonlocation /c/Python39



  Windows installers are built using

  * [Pynsist](https://pynsist.readthedocs.io/en/latest/).

  * [NSIS](http://nsis.sourceforge.net/Main_Page) is also needed.

  To build the installer using Pynsist run:

      ./contrib/win32/run-pynsist.sh

  This will generate an installer in `build/nsis/`.



  You may need to configure your history browser if you are upgrading from an
  older version of Git Cola on Windows.

  `gitk` was originally the default history browser, but `gitk` cannot be
  launched as-is on Windows because `gitk` is a shell script.

  If you are configured to use `gitk`, then change your configuration to
  go through Git's `sh.exe` on Windows.  Similarly, we must go through
  `python.exe` if we want to use `git-dag`.

  If you want to use gitk as your history browser open the
  Preferences screen and change the history browser command to:

      "C:/Program Files/Git/bin/sh.exe" --login -i C:/Git/bin/gitk

  `git-dag` became the default history browser on Windows in `v2.3`, so new
  users do not need to configure anything.

rpm_license:
  GNU GENERAL PUBLIC LICENSE Version 2, June 1991  Copyright (C) 1989, 1991 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.  Preamble  The licenses for most software are designed to take away your freedom to share and change it.  By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.  This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it.  (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.)  You can apply it to your programs, too.  When we speak of free software, we are referring to freedom, not price.  Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.  To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.  For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have.  You must make sure that they, too, receive or can get the source code.  And you must show them these terms so they know their rights.  We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.  Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software.  If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.  Finally, any free program is threatened constantly by software patents.  We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary.  To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.  The precise terms and conditions for copying, distribution and modification follow.  GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION  0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License.  The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.  (Hereinafter, translation is included without limitation in the term "modification".)  Each licensee is addressed as "you".  Activities other than copying, distribution and modification are not covered by this License; they are outside its scope.  The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.  1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.  You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.  2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:  a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.  b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.  c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License.  (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)  These requirements apply to the modified work as a whole.  If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.  But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.  Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.  In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.  3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:  a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,  b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,  c) Accompany it with the information you received as to the offer to distribute corresponding source code.  (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)  The source code for a work means the preferred form of the work for making modifications to it.  For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.  However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.  If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.  4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License.  Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.  5. You are not required to accept this License, since you have not signed it.  However, nothing else grants you permission to modify or distribute the Program or its derivative works.  These actions are prohibited by law if you do not accept this License.  Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.  6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions.  You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.  7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License.  If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all.  For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.  If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.  It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices.  Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.  This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.  8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded.  In such case, this License incorporates the limitation as if written in the body of this License.  9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time.  Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.  Each version is given a distinguishing version number.  If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation.  If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.  10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission.  For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this.  Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.  NO WARRANTY  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.  END OF TERMS AND CONDITIONS  How to Apply These Terms to Your New Programs  If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.  To do so, attach the following notices to the program.  It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.  <one line to give the program's name and a brief idea of what it does.> Copyright (C) <year>  <name of author>  This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.  This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more details.  You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.  Also add information on how to contact you by electronic and paper mail.  If the program is interactive, make it output a short notice like this when it starts in an interactive mode:  Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.  The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License.  Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program.  You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary.  Here is a sample; alter the names:  Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker.  <signature of Ty Coon>, 1 April 1989 Ty Coon, President of Vice  This General Public License does not permit incorporating your program into proprietary programs.  If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library.  If this is what you want to do, use the GNU Lesser General Public License instead of this License.


pkgId: a1bba6f05e24e0f0d8c7c08667ae049ce59f160b5218db9594c781b240aa948e
name: python-git-secret-protector-help
arch: noarch
version: 1.2.0
epoch: 0
release: 1
summary: Development documents and examples for git-secret-protector
url: https://pypi.org/project/git-secret-protector/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-git-secret-protector-1.2.0-1.src.rpm
location_href: Packages/python-git-secret-protector-help-1.2.0-1.noarch.rpm
checksum_type: sha256
description:
  `git-secret-protector` is a Python-based CLI tool designed to securely manage and protect sensitive files in your Git repositories. It integrates with Cloud Secret Storage Services to encrypt and decrypt secrets, ensuring that your sensitive data remains secure throughout your development process.



  - **AES Key Management**: Securely create, manage, and rotate AES data keys using Cloud Secret Storage Services such as AWS Parameter Store, Google Cloud Secret Manager.
  - **File Encryption/Decryption**: Automatically encrypt and decrypt files in your repository based on patterns defined in the `.gitattributes` file.
  - **Cache Management**: Cache AES data keys locally to improve performance and reduce redundant calls to Cloud Services.





  - pipx ([Download](https://pipx.pypa.io/stable/installation/))

  You can install the `git-secret-protector` module via pipx:

  ```sh
  pipx install git-secret-protector
  ```







  Create a `.gitattributes` file in the root of your repository to define which files should be encrypted.

  Sample `.gitattributes` file:

  ```
  dev/secrets* filter=sample-app-dev diff=sample-app-dev

  prod/secrets* filter=sample-app-prod diff=sample-app-prod

  .gitattributes !filter !diff
  ```



  Set up the Git clean and smudge filters base on the filters defined in the `.gitattributes` file.

  ```sh
  git-secret-protector setup-filters
  ```

  This command will configure the Git clean and smudge filters based on the patterns defined in the `.gitattributes` file. The filters will automatically encrypt and decrypt files based on the specified patterns.




  The `config.ini` file contains settings that customize the behavior of the `git-secret-protector` module. The file should be located in the module's directory (by default: `.git_secret_protector/config.ini`) and can be used to override the default values set in the code.

  - Sample `config.ini`

    ```ini
    [DEFAULT]
    module_name = git-secret-protector
    log_file = /path/to/log/git_secret_protector.log
    log_level = INFO
    log_max_size = 1048576
    log_backup_count = 3
    magic_header = ENCRYPTED
    storage_type = AWS_SSM
    ```
  - Configuration Parameters

    - `module_name`: Name of the module.
    - `log_file`: Path to the log file.
    - `log_level`: Log level (DEBUG, INFO, WARNING, ERROR, CRITICAL).
    - `log_max_size`: Maximum size of the log file in bytes.
    - `log_backup_count`: Number of log files to keep.
    - `magic_header`: Magic header to identify encrypted files.
    - `storage_type`: Cloud Secret Storage Service to use (AWS_SSM, GCP_SECRET_MANAGER).
      - AWS_SSM (default): AWS Parameter Store
      - GCP_SECRET: Google Cloud Secret Manager



  Before executing this command, ensure you have the necessary permissions to manage resources in the using Cloud Secret Storage Services.

  ```sh
  git-secret-protector setup-aes-key <filter_name>
  ```

  Sample command to set up an AES key for the `sample-app-dev` filter:

  ```sh
  git-secret-protector setup-aes-key sample-app-dev
  ```





  Before encrypting or decrypting files, it's necessary to retrieve the relevant AES keys from the Cloud Secret Storage Service for filters:

  ```sh
  git-secret-protector pull-aes-key <filter_name>
  ```

  This command fetches the latest AES data key and IV from the Cloud Secret Storage Service for the designated filter and caches them locally for subsequent operations. This step ensures that you have the correct keys for encryption or decryption tasks related to the specified filter.



  Set up the Git clean and smudge filters base on the filters defined in the `.gitattributes` file.

  ```sh
  git-secret-protector setup-filters
  ```



  To decrypt secret files, you can use the following command:

  ```sh
  git-secret-protector decrypt-files <filter_name>
  ```





  Command to obtain a comprehensive overview of the encryption status of files within the repository:

  ```sh
  git-secret-protector status
  ```



  In case you need to rotate the AES key due to security reasons or a team member leaving the project, you can rotate the keys using the following command:

  - Command to Rotate Keys

    ```sh
    git-secret-protector rotate-key <filter_name>
    ```

  - This command will execute the following steps:
    - Generate a new AES data key in AWS Parameter Store
    - Re-encrypt your files associated with the specified filter with the new key
    - Update the local cache.


  - Post-Rotation Code Reset:

    After rotating the keys, it is necessary to clear the Git cache and re-checkout all files. This step ensures that the smudge filters are triggered, allowing the files to be decrypted with the new key.

    ```
    
    git rm --cached -r .

    
    git reset --hard
    ```



  Logs are stored in the `logs/` directory by default, and you can configure the log level and file rotation in the `config.ini` file.





  - **Unit Tests**: Located in the `tests/unit` directory, run them using `pytest`.

    ```sh
    poetry run pytest tests/unit
    ```

  - **Integration Tests**: Located in the `tests/integration` directory, these tests interact with Secret Store in cloud and should be run manually.


    ```sh
    poetry run pytest tests/integration
    ```



  See [CHANGELOG.md](CHANGELOG.md) for a history of changes and updates.



  If you encounter any issues or have any questions, please open an issue on the GitHub repository or reach out to our support team.


pkgId: c20e459251ac30fe530d6db112db8dfae4258d1fd770b061f65b19d72cd7b72b
name: python-git-substitute-help
arch: noarch
version: 0.1.2
epoch: 0
release: 1
summary: Development documents and examples for git-substitute
url: https://pypi.org/project/git-substitute/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-git-substitute-0.1.2-1.src.rpm
location_href: Packages/python-git-substitute-help-0.1.2-1.noarch.rpm
checksum_type: sha256
description:
  [![PyPI](https://img.shields.io/pypi/v/git-substitute)](https://pypi.org/project/git-substitute/)
  [![tests](https://github.com/RobertoRoos/git-substitute/actions/workflows/tests.yml/badge.svg)](https://github.com/RobertoRoos/git-substitute/actions)

  This repository contains a basic tool to generate files with Git information through templates.
  A typical application could be embedding Git version info into source code right before compilation.

  For many modern platforms, this is not relevant.
  In Python you can get version info automatically already through `setuptools` or `poetry` backends and in C++ you could configure CMake to do the same.
  But some more old-fashioned platforms, like TwinCAT PLC, don't have such options and then a tool like this could come in handy.



  ```
  usage: git_substitute [-h] [--output OUTPUT | --stdout] [--exact-only] [--repo REPO] [--verbose] [--quiet] [--version] template

  Generate files with information from Git, based on templates.

  positional arguments:
    template              Path to the template file. If this filename ends with `_template`, `_Template` or `Template`, and no other options are supplied, the output will be a similar file without this suffix.

  options:
    -h, --help            show this help message and exit
    --output OUTPUT, -o OUTPUT
                          Output is saved to this file
    --stdout              Echo result to the terminal instead
    --exact-only          Without this flag, the repository is searched a level higher, with this flag only the specified directory is considered
    --repo REPO, -r REPO  Set explicit root to Git repository (by default, start searching for current directory)
    --verbose, -v         Print information to the terminal
    --quiet, -q           Print logs to stderr instead of stdout
    --version, -V         show program's version number and exit
  ```



  The recommended system-wide install is through [pipx](https://pipx.pypa.io/stable/): `pipx install git-substitute`

  You can also install it regularly through pip (in your `venv`): `pip install git-substitute`.

  Or from a local clone, run `poetry install` or `pip install . [-e]`.
  You could also install directly from git with `pip install https://github.com/RobertoRoos/git-substitute`.





  Run as either `git_substitute ...` or `python -m git_substitute ...`.

  Typical usage: `git_substitute current_version_template.cs`.
  This will copy the template file, substitute Git variables and commands and create a new file with a similar name, but without `_template` in the name.

  See `git_substitute --help` for all options.



  Use `{{...}}` in template file for placeholders.
  There are types of content: variables and direct Git function calls.

  Variables are in uppercase with underscores, and start with `GIT_`.
  E.g.: `{{GIT_TAG}}`.

  Instead of predefined variables you could use direct calls to Git.
  These are lowercase and start with `git ...`.
  E.g. `{{git refname --dirty}}`.
  Note that the interface through GitPython is used, instead of opening a shell directly.



  In case you are not sure what information to embed, use `GIT_DESCRIPTION_DIRTY` as it is very concise and clear.

  | Placeholder           | Description                                                                                                     | Example                                  |
  |-----------------------|-----------------------------------------------------------------------------------------------------------------|------------------------------------------|
  | GIT_HASH              | Full hash of the last commit                                                                                    | 4cc498b3c37375d8d9138fdab553ced012cafc7a |
  | GIT_HASH_SHORT        | 8-char hash of the last commit                                                                                  | 4cc498b3                                 |
  | GIT_DATE              | Datetime of the last commit                                                                                     | 17-12-2024 12:47:10                      |
  | GIT_NOW               | The current date and time, not a git command at all                                                             | 19-12-2024 16:20:35                      |
  | GIT_TAG               | Most relevant tag (result of `git tag`)                                                                         | v1.0.0                                   |
  | GIT_VERSION           | Guaranteed 3-digit `1.2.3` like-string, based on most relevant tag                                              | 1.0.0                                    |
  | GIT_BRANCH            | Current branch name                                                                                             | master                                   |
  | GIT_DESCRIPTION       | Most relevant tag + number of commits since then + last commit  (result of `git describe --tags --always`)      | v0.0.1-1-g4cc498b                        |
  | GIT_DESCRIPTION_DIRTY | Same as `GIT_DESCRIPTION`, except it also adds the `--dirty` argument to mark if there were uncommitted changes | v0.0.1-1-g4cc498b-dirty                  |
  | GIT_DIRTY             | `1` if there are uncommited chances, otherwise `0`                                                              | 0                                        |

  To use literal placeholder symbols in your template, escape them with a backslash: `\{\{` and `\}\}`.



  ```c++
  // File: src/version_template.cpp



  // Specificy the version for this library
  const std::string version = "{{GIT_DESCRIPTION_DIRTY}}";
  ```

  Then in your build script you may have a step like:
  ```shell
  git_substitute src/version_template.cpp
  ```

  Which will create `src/version.cpp` and can be compiled into your application.



  Install with development dependencies with `poetry install --with dev`.

  [Poetry Dynamic Versioning](https://pypi.org/project/poetry-dynamic-versioning/) is used for automatic version detection.



  The package is published to PyPi, at https://pypi.org/project/git-substitute/.

  Publishing is now done manually, through `poetry build` and `poetry publish`.


pkgId: 95691d801907359eb80d2795d9a1d39accdcf8e7b2b894ad783b04b859df3edd
name: python-gitfiles-help
arch: noarch
version: 1.0.0
epoch: 0
release: 1
summary: Development documents and examples for gitfiles
url: https://github.com/legopitstop/gitfiles/
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gitfiles-1.0.0-1.src.rpm
location_href: Packages/python-gitfiles-help-1.0.0-1.noarch.rpm
checksum_type: sha256
description:
  [![PyPI](https://img.shields.io/pypi/v/gitfiles)](https://pypi.org/project/gitfiles/)
  [![Python](https://img.shields.io/pypi/pyversions/gitfiles)](https://www.python.org/downloads//)
  ![Downloads](https://img.shields.io/pypi/dm/gitfiles)
  ![Status](https://img.shields.io/pypi/status/gitfiles)
  [![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/ambv/black)
  [![Issues](https://img.shields.io/github/issues/legopitstop/gitfiles)](https://github.com/legopitstop/gitfiles/issues)

  Load, filter and match `.gitingore` files.



  Install the module with pip:

  ```bat
  pip3 install gitfiles
  ```

  Update existing installation: `pip3 install gitfiles --upgrade`



  ```Python
  import gitfiles

  print(gitfiles.match('file.so'))
  ```

  ```Python
  import gitfiles

  files = [
      '.venv',
      '.env',
      'app.py'
  ]
  print(gitfiles.filter(files))
  ```


pkgId: be475909d391c19cdc5c33d5d6ff05f9959af13fe266c5c78b2112a3a55db3e4
name: python-github-webhook-server-help
arch: noarch
version: 2.0.3
epoch: 0
release: 1
summary: Development documents and examples for github-webhook-server
url: https://pypi.org/project/github-webhook-server/
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-github-webhook-server-2.0.3-1.src.rpm
location_href: Packages/python-github-webhook-server-help-2.0.3-1.noarch.rpm
checksum_type: sha256
description:
  A [FastAPI-based](https://fastapi.tiangolo.com) webhook server for managing GitHub pull requests workflow. and manage repositories.



  The tool will manage the following:



  - Configure repositories setting
  - Configure branch protection
  - Set itself as webhook for the repository
  - Add missing lables to the repository



  - Add reviewers from OWNER file
  - Manage pull requests labels
  - Check when the pull request is ready to be merged
  - Build container from Dockerfile when pull request is merged
  - Build container from Dockerfile when new release is pushed
  - Push new release to PyPI when new release is pushed
  - Open an issue for each pull request
  - Add pull request size label



  - Mark pull request as WIP by comment /wip to the pull request, To remove it from the pull request comment /wip cancel to the pull request.
  - Block merging of pull request by comment /hold, To un-block merging of pull request comment /hold cancel.
  - Mark pull request as verified by comment /verified to the pull request, to un-verify comment /verified cancel to the pull request.
    - verified label removed on each new commit push.
  - Cherry pick a merged pull request comment /cherry-pick <target branch to cherry-pick to> in the pull request.
    - Multiple target branches can be cherry-picked, separated by spaces. (/cherry-pick branch1 branch2)
    - Cherry-pick will be started when pull request is merged
  - Build and push container image command /build-and-push-container in the pull request (tag will be the pull request number).
    - You can add extra args to the Podman build command
      - Example: /build-and-push-container --build-arg OPENSHIFT_PYTHON_WRAPPER_COMMIT=<commit_hash>
  - Add a label by comment use /<label name>, to remove, use /<label name> cancel
  - Assign reviewers based on OWNERS file use /assign-reviewers
  - Check if pull request can be merged use /check-can-merge

  Pre-build container images available in:

  - quay.io/myakove/github-webhook-server



  Webhook server to manage GitHub repositories.
  On start, it will configure the following for each repository:

  - Set branch protection based on config.yaml

  **Private repositories are not supported.**



  Using podman:

  ```bash
  podman build --format docker -t github-webhook-server .
  ```

  Using docker:

  ```bash
  docker build -t github-webhook-server .
  ```



  [example.config.yaml](https://github.com/myakove/github-webhook-server/blob/main/example.config.yaml)
  [docker-compose-example.yaml](https://github.com/myakove/github-webhook-server/blob/main/docker-compose-example.yaml)





  Before running the application, ensure to set the following environment variables and configuration file:

  - `WEBHOOK_SERVER_LOG_FILE`: Path to the log file where the server logs are to be stored.
  - `WEBHOOK_SERVER_DATA_DIR`: Path to the data directory where the `config.yaml` file is located.
  - `WEBHOOK_SERVER_LOG_LEVEL`: App log level.
  - `config.yaml`: Configuration file that contains settings for the server and repositories, which should be placed in the `WEBHOOK_SERVER_DATA_DIR` directory.

  Follow the instructions to build the container using either podman or docker as described in the Build container section. Once that is done, proceed with the configurations outlined below.



  Minimum config to get started

  ```yaml
  github-app-id: 123456
  webhook_ip: https://IP or FQDN
  github-toekns:
    - <GITHIB TOKEN1>

  repositories:
    my-repository-name:
      name: my-org/my-repository-name
      protected-branches:
        main: []
  ```

  - `github-app-id`: The ID of the GitHub app. Need to add the APP to the repository.
  - `name`: repository full name (org or user/repository name)
  - `webhook_ip`: Ip or FQDN where this app will run, this will be added as webhook in the repository setting
  - `github-toekns`: List of admin users token for the repositories

  - If `slack_webhook_url` configured for the repository a slack massages will be sent to the configured channel
    about new releases to pypi, new containers that was pushed

  ```yaml
  slack_webhook_url: https://hooks.slack.com/services/<channel>
  ```

  if `pypi` configured for the repository a new version will be pushed to pypi on new GitHub release

  - `token`: pypi token with push permissions
  - `tool`: The tool to use to build the package, can be `twine` or `poetry`

  ```yaml
  pypi:
    token: pypi-token
    tool: twine
  ```

  if `tox` configured for the repository a tox job will run on each push and new commits

  - `tox`: The tox tests to run, can be set of tests separated by `,` or `all` to run all tests defined in tox.ini

  ```yaml
  tox: all
  tox_python_version: python3.11 # if passed run on specified python version else run on default
  ```

  Top level array which define the defaults required check runs for all the repositories

  ```yaml
  default-status-checks:
    - "WIP"
    - "dpulls"
    - "SonarCloud Code Analysis"
    - "can-be-merged"
  ```

  ```yaml
  protected-branches:
    main: []
  ```

  This tool configure branch protection and set required to be run for each branch to pass before the pull request can be merged

  if the repository have the file `.pre-commit-config.yaml` then `pre-commit.ci - pr` will be added, can be excluded by
  set it in `exclude-runs`

  - `protected-branches`: array of branches to set protection
  - `branch name`: List of required to be run to set for the branch, when empty set `default-status-checks` as required
  - `include-runs`: Only include those runs as required
  - `exclude-runs`: Exclude those runs from the `default-status-checks`

  By default, we create a `verified_job` run, for each pull request the owner needs to comment `/verified` to mark the pull request as verified
  In order to not add this job set `verified_job` to `false`

  ```yaml
  verified_job: false
  ```

  if `container` is configured for the repository we create `build-container` run that will build the container on each
  pull request push/commit
  Once the pull request is merged, the container will be build and push to the repository
  if `release` is set to `true` a new container will be pushed with the release version as the tag
  if the merged pull request is in any other branch than `main` or `master` the tag will be set to `branch name`, otherwise `tag` will be used

  - `username`: User with push permissions to the repository
  - `password`: The password for the username
  - `repository`: the repository to push the container, for example `quay.io/myakove/github-webhook-server`
  - `tag`: The container tag to use when pushing the container
  - `release`: if `true` a new container will be pushed with the release version as the tag

  ```yaml
  container:
    username: username
    password: password
    repository: repository path
    tag: latest
    release: true
  ```

  If `docker` is configured for the repository we log in to docker.io to increase pull rate limit

  ```yaml
  docker:
    username: username
    password: password
  ```

  if Jira is configured for the repository we create a new issue (story) for the pull request and assign it to the owner.
  On new commit create closed sub-task under the pull request story with the commiter as assignee
  On reviewed pull request create closed sub-task under the pull request story with the reviewer as assignee

  - `server`: FQDN Jira server url
  - `project`: project key to open the issue
  - `token`: Jira token
  - `epic`: epic name, if provided a new issue will be created under the epic
  - `user-mapping`: mapping from github username to jira username if different

  `jira` setting can be placed as global (for all repositories) or per repository.
  `jira` in repository setting will override `jira` in global setting for the repository

  ```yaml
  jira:
    server: jira server url
    project: project key to open the issue
    token: jira token
    epic: epic name # Optional
    user-mapping:
      github username: jira username
  ```

  To enable jira for a repository, set `jira-tracking: true` in repository settings

  ```yaml
  repositories:
    my-repository:
      jira-tracking: true
  ```



  Following actions are done automatically:

  - Add reviewers from [OWNERS](OWNERS) file, support add different reviewers based on files/folders.
  - Set pull request size label.
  - New issue is created for the pull request.
  - Issues get closed when pull request is merged/closed.



  ```yaml
  approvers:
    - myakove
    - rnetser
  reviewers:
    - myakove
    - rnetser
  ```



  - `/verified`: to verify a pull request
  - `/verified cancel`: to undo verify
  - `/cherry-pick <target_branch_name>`: cherry-pick a merged pull request against a target branch
    - Multiple target branches are allowed, separated by spaces
    - If the current pull request is nor merged label will be added and once the pull request is merged it will be cherry-picked
  - `/retest tox`: run tox
  - `/retest build-container`: run build-container
  - `/retest python-module-install`: run python-module-install command
  - `/retest all`: run all tests
  - `/build-and-push-container`: build and push container image (tag will be the pull request number)
    - You can add extra args to the Podman build command
      - Example: `/build-and-push-container --build-arg OPENSHIFT_PYTHON_WRAPPER_COMMIT=<commit_hash>`
  - `/assign-reviewers`: assign reviewers based on OWNERS file



  Usage:

  - `/<label name>`: add a label to a pull request
  - `/<label name> cancel`: remove label

  Supported labels:

  - hold
  - verified
  - wip
  - lgtm
  - approve



  - verified label removed on each new commit push.
  - Cherry-picking is supported only on merged pull requests



  - New issues can be created for this project [here](https://github.com/myakove/github-webhook-server/issues)





  The webhook server configures custom logging with color-coded log level names to enhance readability. It also supports optional logging to a file.
  See [example-config](example.config.yaml) for more details.



  Webhooks are automatically created for GitHub repositories based on settings defined in `webhook.py`. These webhooks enable real-time integration with GitHub events such as push, pull requests, and more.



  To use the webhook server, first prepare the [config.yaml](example.config.yaml) file with the necessary repository and server configurations. Set the required environment variables, including `WEBHOOK_SERVER_DATA_DIR`. Build and start the server using the instructions in the 'Build container' section.


pkgId: 129e0ab105ec9bb5101f89e4c26e730e93cf3979c748b1b053f9667d1161b395
name: python-gitlab-ci-verify-help
arch: noarch
version: 0.6.0
epoch: 0
release: 1
summary: Development documents and examples for gitlab-ci-verify
url: https://pypi.org/project/gitlab-ci-verify/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gitlab-ci-verify-0.6.0-1.src.rpm
location_href: Packages/python-gitlab-ci-verify-help-0.6.0-1.noarch.rpm
checksum_type: sha256
description:
  [![GitHub Release](https://img.shields.io/github/v/release/timo-reymann/gitlab-ci-verify?label=version)](https://github.com/timo-reymann/gitlab-ci-verify/releases/latest)
  [![PyPI version](https://badge.fury.io/py/gitlab-ci-verify.svg)](https://pypi.org/project/gitlab-ci-verify)
  [![DockerHub Pulls](https://img.shields.io/docker/pulls/timoreymann/gitlab-ci-verify)](https://hub.docker.com/r/timoreymann/gitlab-ci-verify)
  [![GitHub all releases download count](https://img.shields.io/github/downloads/timo-reymann/gitlab-ci-verify/total)](https://github.com/timo-reymann/gitlab-ci-verify/releases)
  [![CircleCI](https://dl.circleci.com/status-badge/img/gh/timo-reymann/gitlab-ci-verify/tree/main.svg?style=shield)](https://dl.circleci.com/status-badge/redirect/gh/timo-reymann/gitlab-ci-verify/tree/main)
  [![codecov](https://codecov.io/gh/timo-reymann/gitlab-ci-verify/graph/badge.svg?token=4tYXDueu5D)](https://codecov.io/gh/timo-reymann/gitlab-ci-verify)
  [![Renovate](https://img.shields.io/badge/renovate-enabled-green?logo=data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAzNjkgMzY5Ij48Y2lyY2xlIGN4PSIxODkuOSIgY3k9IjE5MC4yIiByPSIxODQuNSIgZmlsbD0iI2ZmZTQyZSIgdHJhbnNmb3JtPSJ0cmFuc2xhdGUoLTUgLTYpIi8+PHBhdGggZmlsbD0iIzhiYjViNSIgZD0iTTI1MSAyNTZsLTM4LTM4YTE3IDE3IDAgMDEwLTI0bDU2LTU2YzItMiAyLTYgMC03bC0yMC0yMWE1IDUgMCAwMC03IDBsLTEzIDEyLTktOCAxMy0xM2ExNyAxNyAwIDAxMjQgMGwyMSAyMWM3IDcgNyAxNyAwIDI0bC01NiA1N2E1IDUgMCAwMDAgN2wzOCAzOHoiLz48cGF0aCBmaWxsPSIjZDk1NjEyIiBkPSJNMzAwIDI4OGwtOCA4Yy00IDQtMTEgNC0xNiAwbC00Ni00NmMtNS01LTUtMTIgMC0xNmw4LThjNC00IDExLTQgMTUgMGw0NyA0N2M0IDQgNCAxMSAwIDE1eiIvPjxwYXRoIGZpbGw9IiMyNGJmYmUiIGQ9Ik04MSAxODVsMTgtMTggMTggMTgtMTggMTh6Ii8+PHBhdGggZmlsbD0iIzI1YzRjMyIgZD0iTTIyMCAxMDBsMjMgMjNjNCA0IDQgMTEgMCAxNkwxNDIgMjQwYy00IDQtMTEgNC0xNSAwbC0yNC0yNGMtNC00LTQtMTEgMC0xNWwxMDEtMTAxYzUtNSAxMi01IDE2IDB6Ii8+PHBhdGggZmlsbD0iIzFkZGVkZCIgZD0iTTk5IDE2N2wxOC0xOCAxOCAxOC0xOCAxOHoiLz48cGF0aCBmaWxsPSIjMDBhZmIzIiBkPSJNMjMwIDExMGwxMyAxM2M0IDQgNCAxMSAwIDE2TDE0MiAyNDBjLTQgNC0xMSA0LTE1IDBsLTEzLTEzYzQgNCAxMSA0IDE1IDBsMTAxLTEwMWM1LTUgNS0xMSAwLTE2eiIvPjxwYXRoIGZpbGw9IiMyNGJmYmUiIGQ9Ik0xMTYgMTQ5bDE4LTE4IDE4IDE4LTE4IDE4eiIvPjxwYXRoIGZpbGw9IiMxZGRlZGQiIGQ9Ik0xMzQgMTMxbDE4LTE4IDE4IDE4LTE4IDE4eiIvPjxwYXRoIGZpbGw9IiMxYmNmY2UiIGQ9Ik0xNTIgMTEzbDE4LTE4IDE4IDE4LTE4IDE4eiIvPjxwYXRoIGZpbGw9IiMyNGJmYmUiIGQ9Ik0xNzAgOTVsMTgtMTggMTggMTgtMTggMTh6Ii8+PHBhdGggZmlsbD0iIzFiY2ZjZSIgZD0iTTYzIDE2N2wxOC0xOCAxOCAxOC0xOCAxOHpNOTggMTMxbDE4LTE4IDE4IDE4LTE4IDE4eiIvPjxwYXRoIGZpbGw9IiMzNGVkZWIiIGQ9Ik0xMzQgOTVsMTgtMTggMTggMTgtMTggMTh6Ii8+PHBhdGggZmlsbD0iIzFiY2ZjZSIgZD0iTTE1MyA3OGwxOC0xOCAxOCAxOC0xOCAxOHoiLz48cGF0aCBmaWxsPSIjMzRlZGViIiBkPSJNODAgMTEzbDE4LTE3IDE4IDE3LTE4IDE4ek0xMzUgNjBsMTgtMTggMTggMTgtMTggMTh6Ii8+PHBhdGggZmlsbD0iIzk4ZWRlYiIgZD0iTTI3IDEzMWwxOC0xOCAxOCAxOC0xOCAxOHoiLz48cGF0aCBmaWxsPSIjYjUzZTAyIiBkPSJNMjg1IDI1OGw3IDdjNCA0IDQgMTEgMCAxNWwtOCA4Yy00IDQtMTEgNC0xNiAwbC02LTdjNCA1IDExIDUgMTUgMGw4LTdjNC01IDQtMTIgMC0xNnoiLz48cGF0aCBmaWxsPSIjOThlZGViIiBkPSJNODEgNzhsMTgtMTggMTggMTgtMTggMTh6Ii8+PHBhdGggZmlsbD0iIzAwYTNhMiIgZD0iTTIzNSAxMTVsOCA4YzQgNCA0IDExIDAgMTZMMTQyIDI0MGMtNCA0LTExIDQtMTUgMGwtOS05YzUgNSAxMiA1IDE2IDBsMTAxLTEwMWM0LTQgNC0xMSAwLTE1eiIvPjxwYXRoIGZpbGw9IiMzOWQ5ZDgiIGQ9Ik0yMjggMTA4bC04LThjLTQtNS0xMS01LTE2IDBMMTAzIDIwMWMtNCA0LTQgMTEgMCAxNWw4IDhjLTQtNC00LTExIDAtMTVsMTAxLTEwMWM1LTQgMTItNCAxNiAweiIvPjxwYXRoIGZpbGw9IiNhMzM5MDQiIGQ9Ik0yOTEgMjY0bDggOGM0IDQgNCAxMSAwIDE2bC04IDdjLTQgNS0xMSA1LTE1IDBsLTktOGM1IDUgMTIgNSAxNiAwbDgtOGM0LTQgNC0xMSAwLTE1eiIvPjxwYXRoIGZpbGw9IiNlYjZlMmQiIGQ9Ik0yNjAgMjMzbC00LTRjLTYtNi0xNy02LTIzIDAtNyA3LTcgMTcgMCAyNGw0IDRjLTQtNS00LTExIDAtMTZsOC04YzQtNCAxMS00IDE1IDB6Ii8+PHBhdGggZmlsbD0iIzEzYWNiZCIgZD0iTTEzNCAyNDhjLTQgMC04LTItMTEtNWwtMjMtMjNhMTYgMTYgMCAwMTAtMjNMMjAxIDk2YTE2IDE2IDAgMDEyMiAwbDI0IDI0YzYgNiA2IDE2IDAgMjJMMTQ2IDI0M2MtMyAzLTcgNS0xMiA1em03OC0xNDdsLTQgMi0xMDEgMTAxYTYgNiAwIDAwMCA5bDIzIDIzYTYgNiAwIDAwOSAwbDEwMS0xMDFhNiA2IDAgMDAwLTlsLTI0LTIzLTQtMnoiLz48cGF0aCBmaWxsPSIjYmY0NDA0IiBkPSJNMjg0IDMwNGMtNCAwLTgtMS0xMS00bC00Ny00N2MtNi02LTYtMTYgMC0yMmw4LThjNi02IDE2LTYgMjIgMGw0NyA0NmM2IDcgNiAxNyAwIDIzbC04IDhjLTMgMy03IDQtMTEgNHptLTM5LTc2Yy0xIDAtMyAwLTQgMmwtOCA3Yy0yIDMtMiA3IDAgOWw0NyA0N2E2IDYgMCAwMDkgMGw3LThjMy0yIDMtNiAwLTlsLTQ2LTQ2Yy0yLTItMy0yLTUtMnoiLz48L3N2Zz4=)](https://renovatebot.com)
  [![Quality Gate Status](https://sonarcloud.io/api/project_badges/measure?project=timo-reymann_gitlab-ci-verify&metric=alert_status)](https://sonarcloud.io/summary/new_code?id=timo-reymann_gitlab-ci-verify)
  [![Maintainability Rating](https://sonarcloud.io/api/project_badges/measure?project=timo-reymann_gitlab-ci-verify&metric=sqale_rating)](https://sonarcloud.io/summary/new_code?id=timo-reymann_gitlab-ci-verify)
  [![Go Report Card](https://goreportcard.com/badge/github.com/timo-reymann/gitlab-ci-verify)](https://goreportcard.com/report/github.com/timo-reymann/gitlab-ci-verify)
  [![Security Rating](https://sonarcloud.io/api/project_badges/measure?project=timo-reymann_gitlab-ci-verify&metric=security_rating)](https://sonarcloud.io/summary/new_code?id=timo-reymann_gitlab-ci-verify)
  <p align="center">
  	<img width="300" src="https://raw.githubusercontent.com/timo-reymann/gitlab-ci-verify/main/.github/images/logo.png">
      <br />
      Validate and lint your gitlab ci files using ShellCheck, the Gitlab API and curated checks
  </p>

  - ShellCheck for scripts
  - Validation against Pipeline Editor API for project
  - Curated checks for common mistakes (feel free to [contribute new ones](./docs/checks/Add_check.md))
  - Automatic detection of the current gitlab project with an option to overwrite
  - Available as pre-commit hook
  - Use to valid dynamically generated pipelines using the [python wrapper](#install-as-library-using-pip)
  - Support for *gitlab.com* and self-hosted instances

  | Format |                                                                Screenshot                                                                |
  |:-------|:----------------------------------------------------------------------------------------------------------------------------------------:|
  | text   |  ![Text output screenshot](https://raw.githubusercontent.com/timo-reymann/gitlab-ci-verify/main/.github/images/example_output/text.png)  |
  | json   |  ![JSON output screenshot](https://raw.githubusercontent.com/timo-reymann/gitlab-ci-verify/main/.github/images/example_output/json.png)  |
  | table  | ![Table output screenshot](https://raw.githubusercontent.com/timo-reymann/gitlab-ci-verify/main/.github/images/example_output/table.png) |




  Using pipx you can just use the following command use gitlab-ci-verify as it is:
  ```sh
  pipx install gitlab-ci-verify-bin
  ```

  If you want to use it directly using the `subprocess` module you can install it with pip:
  ````sh
  pip install gitlab-ci-verify
  ````
  And use the package like this:
  ````python
  from gitlab_ci_verify import verify_file

  valid, findings = verify_file("/path/to/repo")

  valid, findings = verify_file("/path/to/repo", "include.yml")


  print(f"Valid:    {valid}")
  print(f"Findings: {findings}")
  ````
  Also see the [python wrapper documentation](https://timo-reymann.github.io/gitlab-ci-verify/python-wrapper/)


  ```bash
  curl -LO https://github.com/timo-reymann/gitlab-ci-verify/releases/download/$(curl -Lso /dev/null -w %{url_effective} https://github.com/timo-reymann/gitlab-ci-verify/releases/latest | grep -o '[^/]*$')/gitlab-ci-verify_linux-amd64 && \
  chmod +x gitlab-ci-verify_linux-amd64 && \
  sudo mv gitlab-ci-verify_linux-amd64 /usr/local/bin/gitlab-ci-verify
  ```

  ```bash
  curl -LO https://github.com/timo-reymann/gitlab-ci-verify/releases/download/$(curl -Lso /dev/null -w %{url_effective} https://github.com/timo-reymann/gitlab-ci-verify/releases/latest | grep -o '[^/]*$')/gitlab-ci-verify_darwin-amd64 && \
  chmod +x gitlab-ci-verify_darwin-amd64 && \
  sudo mv gitlab-ci-verify_darwin-amd64 /usr/local/bin/gitlab-ci-verify
  ```

  Download the latest [release](https://github.com/timo-reymann/gitlab-ci-verify/releases/latest) for Windows and put in
  your `PATH`.

  ```bash
  go install github.com/timo-reymann/gitlab-ci-verify@latest
  ```

  The following platforms are supported (and have prebuilt binaries /
  ready to use integration):
  - Linux
      - 64-bit
      - ARM 64-bit
  - Darwin
      - 64-bit
      - ARM (M1/M2)
  - Windows
      - 64-bit
  - pre-commit (x86 & ARM)
  - Docker (x86 & ARM)


  Binaries for all of these can be found on
  the [latest release page](https://github.com/timo-reymann/gitlab-ci-verify/releases/latest).

  For the docker image, check the [docker hub](https://hub.docker.com/r/timoreymann/gitlab-ci-verify).


  ```sh
  gitlab-ci-verify --help
  ```

  ```sh
  docker run --rm -it -v $PWD:/workspace -e GITLAB_TOKEN="your token" timoreymann/gitlab-ci-verify
  ```

  ```yaml
  - repo: https://github.com/timo-reymann/gitlab-ci-verify
    rev: v0.6.0
    hooks:
      - id: gitlab-ci-verify
  ```

  The tool takes a few sources into consideration in the following order when authenticating with GitLab:
  - `--gitlab-token` commandline flag
  - [netrc](https://www.gnu.org/software/inetutils/manual/html_node/The-_002enetrc-file.html) in your home folder
  - Vault token specified via `--gitlab-token vault://<path>#<field>` with environment variable `VAULT_ADDR` set to base url for
    vault, and either `VAULT_TOKEN` set or `~/.vault-token` present
  - `GITLAB_TOKEN` environment variable
  For the project detection, all git remote URLs of the repository are tried, and the first URL that returns a valid API
  response is used. In case you cloned via SSH it tries to convert it to the HTTPs host automatically. If the ssh URL
  differs from the HTTPs url you should specify it manually using the `--gitlab-base-url`, without protocol e.g.
  `--gitlab-base-url git.example.com`

  Unfortunately, GitLab didn't provide a tool to validate CI configuration for quite a while.
  Now that changed with the `glab` CLI providing `glab ci lint` but it is quite limited and under the hood just calls the
  new CI Lint API.
  Throughout the years quite some tools evolved, but most of them are either outdated, painful to use or install, and
  basically also provide the lint functionality from the API.
  As most of the logic in pipelines is written in shell scripts via the `*script` attributes these are lacking completely
  from all tools out there as well as the official lint API.
  The goal of gitlab-ci-verify is to provide the stock CI Lint functionality plus shellcheck.
  Completed in the future some
  rules to lint that common patterns are working as intended by GitLab
  and void them from being pushed and leading to unexpected behavior.

  I love your input! I want to make contributing to this project as easy and transparent as possible, whether it's:
  - Reporting a bug
  - Discussing the current state of the configuration
  - Submitting a fix
  - Proposing new features
  - Becoming a maintainer
  To get started please read the [Contribution Guidelines](./CONTRIBUTING.md).


  - [Go](https://go.dev/doc/install)
  - [GNU make](https://www.gnu.org/software/make/)
  - [Python 3.10+](https://www.python.org/downloads/)

  ```sh
  make test-coverage-report
  ```

  ```sh
  make build
  ```

  This whole project wouldn't be possible with the great work of the
  following libraries/tools:
  - [Shellcheck by koalaman](https://github.com/koalaman/shellcheck)
  - [go stdlib](https://github.com/golang/go)
  - [pflag by spf13](https://github.com/spf13/pflag)


pkgId: 348ec627bf10f091eeb78bd9cbedcc9e1ae25a4fcb6fe2ea742d6245f9468773
name: python-gitlab-ps-utils-help
arch: noarch
version: 0.14.1
epoch: 0
release: 1
summary: Development documents and examples for gitlab-ps-utils
url: https://gitlab.com/gitlab-org/professional-services-automation/gitlab-ps-utils
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gitlab-ps-utils-0.14.1-1.src.rpm
location_href: Packages/python-gitlab-ps-utils-help-0.14.1-1.noarch.rpm
checksum_type: sha256
description:
  GitLab PS utils is the foundational API and utilities libraries used by GitLab Professional Services.
  To see the source code, project backlog and contributing guide, [check here](https://gitlab.com/gitlab-org/professional-services-automation/gitlab-ps-utils)



  ```bash
  pip install gitlab-ps-utils
  ```



  This library contains various utility modules and classes.
  Refer to the repository source code to see available utility functions.



  ```python
  from gitlab_ps_utils.string_utils import strip_numbers

  test_var = "abc123"
  print(strip_numbers(test_var))
  ```



  ```python
  from gitlab_ps_utils.api import GitLabApi

  gl_api = GitLabApi()

  gl_api.generate_get_request("http://gitlab.example.com", "token", "/projects")
  ```





  We include a basic GitLab API wrapper class in this library. We will include specific API wrapper functions in the future.
  Our wrapper class and specific wrappers were created when [python-gitlab](https://python-gitlab.readthedocs.io/en/stable/) was in a much earlier state,
  so we continued to use our wrapper instead of switching to python-gitlab

  For generic requests to the GitLab API, our wrapper is more lightweight than python-gitlab,
  but python-gitlab is a great option for more complex API scripts


pkgId: a4242c94403286ba033daea865e418064e2e9445c1187535a8c7fea2e6b174ca
name: python-gitlab_evaluate-help
arch: noarch
version: 0.26.0
epoch: 0
release: 1
summary: Development documents and examples for gitlab_evaluate
url: https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gitlab_evaluate-0.26.0-1.src.rpm
location_href: Packages/python-gitlab_evaluate-help-0.26.0-1.noarch.rpm
checksum_type: sha256
description:
  Evaluate is a script that can be run to gather information about all projects of a GitLab

  - Instance
  - Group (including sub-groups)

  This information is useful to the GitLab Professional Services (PS) team to accurately scope migration services.

  [[_TOC_]]



  This tool is maintained by the Professional Services team and is not included in your GitLab Support if you have a license. For support questions please create [an issue](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate/-/issues/new?issuable_template=evaluate-support) from our [Evaluate support issue template](./.gitlab/issue_templates/evaluate-support.md).



  GitLab PS plans to share this script with a Customer to run against their GitLab instance or group. Then the customer can send back the output files to enable GitLab engagement managers to scope engagements accurately. There is a [single file generated](reading-the-output.md).





  To schedule Evaluate to run on a regular basis we recommend using the following pipeline:

  ```yml
  image: registry.gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate:latest

  stages:
      - evaluate

  run-evaluate:
      stage: evaluate
      timeout: 4h
      script:
          - evaluate-gitlab -t $API_TOKEN -s https://<gitlab-hostname> -p <number-of-processes>
      artifacts:
          name: Report
          paths:
              - evaluate_report.xlsx
          expire_in: 1 week
  ```

  **NOTES:**

  - Configure `API_TOKEN` as CI variable with Admin personal access token and `read_api` or `api` scope
  - Add Runner `tags` for using a `docker` executor and **Linux** Runner
  - Adjust the number of processes based on [recommendation](#recommended-processes-per-project-count)
  - Adjust `timeout` after the 1st run
  - Create pipeline schedule under _Build -> Pipeline schedules_



  [Docker containers with evaluate installed](https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate/container_registry) are also available to use.

  ```bash
  docker pull registry.gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate:latest


  docker run --name evaluate -it registry.gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate:latest /bin/bash


  evaluate-gitlab -t <access-token-with-api-scope> -s https://gitlab.example.com
  evaluate-jenkins -s https://jenkins.example.com -u <jenkins-admin-user> -t <access-token-or-password> # BETA
  evaluate-bitbucket -s https://bitbucket.example.com -t <access-token> # BETA
  evaluate-ado -s https://dev.azure.com/<your-org> -t <personal-access-token> # BETA
  ```



  Requires at least Python 3.8.

  ```bash
  git clone https://gitlab.com/gitlab-org/professional-services-automation/tools/utilities/evaluate.git   # or SSH
  cd evaluate
  pip install gitlab-evaluate
  poetry install


  poetry run evaluate-gitlab -t <access-token-with-api-scope> -s https://gitlab.example.com
  poetry run evaluate-jenkins -s https://jenkins.example.com -u <jenkins-admin-user> -t <access-token-or-password> # BETA
  poetry run evaluate-bitbucket -s https://bitbucket.example.com -t <access-token> # BETA
  poetry run evaluate-ado -s https://dev.azure.com/<your-org> -t <personal-access-token> # BETA
  ```







  Evaluate is meant to be run by an **OWNER** (ideally system **ADMINISTRATOR**) of a GitLab instance to gather data about every project on the instance or group (including sub-groups).

  1. A GitLab **OWNER** (ideally system **ADMINISTRATOR**) should provision an access token with `api` or `read_api` scope:
     - [Personal access token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token) for instance
     - [Group access token](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#create-a-group-access-token-using-ui) for group
  2. Install `gitlab-evaluate` from the [Install](#install-method) section above,
  3. Run :point_down:

      For evaluating a GitLab instance

      ```bash
      evaluate-gitlab -t <access-token-with-api-scope> -s https://gitlab.example.com
      ```

      For evaluating a GitLab group (including sub-groups)

      ```bash
      evaluate-gitlab -t <access-token-with-api-scope> -s https://gitlab.example.com -g 42
      ```

      See [Recommended Processes per Project Count](#recommended-processes-per-project-count) to specify the number of processes to use

  4. This should create a file called `evaluate_report.xlsx`

     For more information on these files, see [reading the output](reading-the-output.md)
  5. If you're coordinating a GitLab PS engagement, email these files to the GitLab account team.



  Evaluate uses 4 processes by default, which is sufficient for smaller GitLab instances, but may result in a slower scan time for larger instances. Below is a table covering recommended processes based on the overall number of projects on an instance:

  | Number of Projects | Recommended Processes |
  | ------------------ | --------------------- |
  | < 100              | 4 (default)           |
  | < 1000             | 8                     |
  | < 10000            | 16                    |
  | < 100000           | 32                    |
  | > 100000           | 64-128                |

  The number of processes is limited by a few factors:

  - API rate limits on the GitLab instance itself
  - Overall stability of the GitLab instance
  - Not as critical as the first two, but overall available memory on the machine running Evaluate is another factor to consider

  You can ramp up the number of processes on a smaller instance to speed up the scans, but the performance gains for a large number of processes on a smaller instance will eventually plateau.



  ```text
  Usage: evaluate-gitlab [OPTIONS]

  Options:
    -s, --source TEXT     Source URL: REQ'd
    -t, --token TEXT      Personal Access Token: REQ'd
    -o, --output          Output Per Project Stats to screen
    -i, --insecure        Set to ignore SSL warnings.
    -g, --group TEXT      Group ID. Evaluate all group projects (including sub-
                          groups)
    -f, --filename TEXT   CSV Output File Name. If not set, will default to
                          'evaluate_output.xlsx'
    -p, --processes TEXT  Number of processes. Defaults to number of CPU cores
    --help                Show this message and exit.
  ```



  Evaluate supports scanning a Jenkins instance to retrieve basic metrics about the instance.

  Evaluate is meant to be run by an admin of a Jenkins instance to gather data about jenkins jobs and any plugins installed on the instance.

  1. A Jenkins **ADMINISTRATOR** should provision an API token for Evaluate to use during the scan.
  2. Install `gitlab-evaluate` from the [Install](#install-method) section above,
  3. Run :point_down:

      ```bash
      evaluate-jenkins -s https://jenkins.example.com -u <jenkins-admin-user> -t <access-token-or-password>
      ```

  4. This should create a file called `evaluate_jenkins.xlsx`
  5. If you're coordinating a GitLab PS engagement, email these files to the GitLab account team.



  ```sh
  Usage: evaluate-jenkins [OPTIONS]

  Options:
    -s, --source TEXT  Source URL: REQ'd
    -u, --user TEXT    Username associated with the Jenkins API token: REQ'd
    -t, --token TEXT   Jenkins API Token: REQ'd
    -i, --insecure     Set to ignore SSL warnings.
    --help             Show this message and exit.
  ```



  Evaluate supports scanning a Bitbucket Server/Data Center to retrieve relevant metadata about the server.

  You can use either a admin or a non-admin token to do the evaluation but non-admin tokens can't pull users information.

  1. A user should provision an access token for Evaluate to use during the scan.
  2. Install `gitlab-evaluate` from the [Install](#install-method) section above,
  3. Run :point_down:

      ```bash
      evaluate-bitbucket -s https://bitbucket.example.com -t <access-token>
      ```

  4. This should create a file called `evaluate_bitbucket.xlsx`
  5. If you're coordinating a GitLab PS engagement, email these files to the GitLab account team.



  ```sh
  Usage: evaluate-bitbucket [OPTIONS]

  Options:
    -s, --source TEXT  Source URL: REQ'd
  REQ'd
    -t, --token TEXT   Bitbucket access Token: REQ'd
    --help             Show this message and exit.
  ```



  Evaluate supports scanning an Azure DevOps to retrieve relevant metadata about the organization.

  You need to use [Personal Access Token](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows) with [Read scope](https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops#scopes) to most of the services.

  1. A user should provision an access token for Evaluate to use during the scan.
  2. Install `gitlab-evaluate` from the [Install](#install-method) section above,
  3. Run :point_down:

      ```bash
      evaluate-ado -s https://dev.azure.com/<your-org> -t <personal-access-token>
      ```

  4. This should create a file called `evaluate_ado.xlsx`
  5. If you're coordinating a GitLab PS engagement, email these files to the GitLab account team.



  ```sh
  Usage: evaluate-ado [OPTIONS]

  Options:
    -s, --source TEXT  Source URL: REQ'd
  REQ'd
    -t, --token TEXT   Azure DevOps Personal Access Token: REQ'd
    --help             Show this message and exit.
  ```



  _Below are the thresholds we will use to determine whether a project can be considered for normal migration or needs to have special steps taken in order to migrate_



  - Project Size - 20GB
  - Pipelines - 5,000 max
  - Issues - 5,000 total (not just open)
  - Merge Requests - 5,000 total (not just merged)
  - Container images - 20GB per project
  - Packages - Any packages present



  - Repository Size - 5GB
  - Commits - 50K
  - Branches - 1K
  - Tags - 5K


pkgId: bed74587e17cd957ec23cf78447f988b901e8d7390dcbd31886e89df38bcc2d2
name: python-gitscout-help
arch: noarch
version: 0.2.0
epoch: 0
release: 1
summary: Development documents and examples for gitscout
url: https://pypi.org/project/gitscout/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gitscout-0.2.0-1.src.rpm
location_href: Packages/python-gitscout-help-0.2.0-1.noarch.rpm
checksum_type: sha256
description:
  This package has been renamed. Use `pip install repo-guide` instead.

  New package: https://pypi.org/project/repo-guide/


pkgId: 4f23841b08b4595e65b89de35f581f3863309bff0e423c2fbfdf5ca0596b6db9
name: python-gittable-help
arch: noarch
version: 0.0.3
epoch: 0
release: 1
summary: Development documents and examples for gittable
url: https://pypi.org/project/gittable/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gittable-0.0.3-1.src.rpm
location_href: Packages/python-gittable-help-0.0.3-1.noarch.rpm
checksum_type: sha256
description:
  [![test](https://github.com/enorganic/gittable/actions/workflows/test.yml/badge.svg?branch=main)](https://github.com/enorganic/gittable/actions/workflows/test.yml)
  [![PyPI version](https://badge.fury.io/py/gittable.svg?icon=si%3Apython)](https://badge.fury.io/py/gittable)

  The package provides a CLI and library for common interactions with a
  Git repository, including: downloading select files from a (public or private)
  Git repository, and tagging commits with your project/package version, when the
  version has changed.

  - [Documentation](https://enorganic.github.io/gittable/)
  - [Contributing](https://enorganic.github.io/gittable/contributing)



  You can install `gittable` with pip:

  ```shell
  pip3 install gittable
  ```


pkgId: 5e5c3b952c00aaf6f1ea96f96c093447dafe3721cd010fa8f8ad56b93c36c86d
name: python-glibby-help
arch: noarch
version: 1.0.0
epoch: 0
release: 1
summary: Development documents and examples for glibby
url: https://github.com/0xRoyR/Glibby
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-glibby-1.0.0-1.src.rpm
location_href: Packages/python-glibby-help-1.0.0-1.noarch.rpm
checksum_type: sha256
description:
  Glibby communicates with the Azure Graph API and Azure Resource Manager (RM) API over HTTPS. It is **not a CLI tool**; instead, it is intended to be imported and used as a Python library within your projects.


pkgId: 7541b160ef65cbd11fdfe8fefd86090cd94a73040e9abcb6bfc978f887f19a72
name: python-glidergun-help
arch: noarch
version: 0.8.1
epoch: 0
release: 1
summary: Development documents and examples for glidergun
url: https://github.com/jshirota/glidergun
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-glidergun-0.8.1-1.src.rpm
location_href: Packages/python-glidergun-help-0.8.1-1.noarch.rpm
checksum_type: sha256
description:
  ```
  pip install glidergun
  ```

  ```python
  from glidergun import grid, mosaic

  dem1 = grid(".data/n55_e008_1arc_v3.bil")
  dem2 = grid(".data/n55_e009_1arc_v3.bil")

  dem = mosaic(dem1, dem2)
  hillshade = dem.hillshade()





  dem, hillshade
  ```

  ![alt text](image1.png)

  ```python
  from glidergun import grid

  band4 = grid(".data/LC08_L2SP_197021_20220324_20220330_02_T1_SR_B4.TIF")
  band5 = grid(".data/LC08_L2SP_197021_20220324_20220330_02_T1_SR_B5.TIF")

  ndvi = (band5 - band4) / (band5 + band4)

  ndvi.plot("gist_earth")
  ```

  ![alt text](image2.png)

  ```python
  from glidergun import animate, grid


  def tick(g):
      count = g.focal_sum() - g
      return (g == 1) & (count == 2) | (count == 3)


  def simulate(g):
      md5s = set()
      while g.md5 not in md5s:
          md5s.add(g.md5)
          yield (g := tick(g))


  seed = grid((50, 50)).randomize() < 0.5

  animate(simulate(seed)).save("game_of_life.gif")
  ```

  ![alt text](game_of_life.gif)


pkgId: 24349de11978d342be5fcd7d1ce024b8b8610a11cdca12911747cb5126cd2945
name: python-globaleaks-eph-fs-help
arch: noarch
version: 0.0.1
epoch: 0
release: 1
summary: Development documents and examples for globaleaks-eph-fs
url: https://github.com/globaleaks/globaleaks-eph-fs
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-globaleaks-eph-fs-0.0.1-1.src.rpm
location_href: Packages/python-globaleaks-eph-fs-help-0.0.1-1.noarch.rpm
checksum_type: sha256
description:
  An ephemeral ChaCha20-encrypted filesystem implementation using fusepy and cryptography suitable for privacy-sensitive applications, such as whistleblowing platforms.

  [![build workflow](https://github.com/globaleaks/globaleaks-eph-fs/actions/workflows/test.yml/badge.svg?branch=main)](https://github.com/globaleaks/globaleaks-eph-fs/actions/workflows/test.yml?query=branch%3Amain) [![Codacy Badge](https://app.codacy.com/project/badge/Grade/16022819c993415e8c82c25fd7654926)](https://app.codacy.com/gh/globaleaks/globaleaks-eph-fs/dashboard) [![Codacy Badge](https://app.codacy.com/project/badge/Coverage/16022819c993415e8c82c25fd7654926)](https://app.codacy.com/gh/globaleaks/globaleaks-eph-fs/dashboard)


  `globaleaks-eph-fs` provides an ephemeral, ChaCha20-encrypted filesystem implementation using Python, FUSE, and Cryptography. This filesystem is designed for temporary, secure storage with strong encryption, making it ideal for privacy-sensitive applications like whistleblowing platforms.



  To install the package, use `pip`:

  ```bash
  pip install globaleaks-eph-fs
  ```





  To mount the filesystem from the command line:

  ```bash
  globaleaks-eph-fs <mountpoint> [--storage_directory <directory>]
  ```

  - `<mountpoint>`: The path where the filesystem will be mounted.
  - `--storage_directory` (optional): The directory used for storage. If not provided, a temporary directory will be used.



  You can also use `globaleaks-eph-fs` within your Python code. Here's an example:

  ```python
  import argparse
  from globaleaks_eph_fs import EphemeralFS

  def main():
      parser = argparse.ArgumentParser(description="GLOBALEAKS EPHEMERAL FS")
      parser.add_argument('mount_point', help="Path to mount the filesystem")
      parser.add_argument('--storage_directory', '-s', help="Optional storage directory. Defaults to a temporary directory.")
      args = parser.parse_args()

      EphemeralFS(args.mount_point, args.storage_directory, nothreads=True, foreground=True)


  if __name__ == '__main__':
      main()
  ```



  - `mount_point` (required): The directory where the encrypted filesystem will be mounted.
  - `--storage_directory` (optional): Specify a custom storage directory for the filesystem. If not provided, a temporary directory will be used.



  - **ChaCha20 Encryption**: All data stored in the filesystem is encrypted with ChaCha20.
  - **FUSE Integration**: Mount the filesystem as a virtual disk using FUSE.
  - **Temporary Storage**: The filesystem is ephemeral and can use a temporary directory for storage.



  - Python 3.7+
  - `fusepy` for FUSE support
  - `cryptography` for encryption



  This project is licensed under the AGPLv3 License - see the [LICENSE](LICENSE) file for details.


pkgId: 72b338665ad905485d56b76d1bcd23f6efdecb14f7c921a3216e0d6da5a1eef1
name: python-globaleaks-ephemeral-fs-help
arch: noarch
version: 0.0.1
epoch: 0
release: 1
summary: Development documents and examples for globaleaks-ephemeral-fs
url: https://github.com/globaleaks/globaleaks-ephemeral-fs
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-globaleaks-ephemeral-fs-0.0.1-1.src.rpm
location_href: Packages/python-globaleaks-ephemeral-fs-help-0.0.1-1.noarch.rpm
checksum_type: sha256
description:
  An ephemeral ChaCha20-encrypted filesystem implementation using fusepy and cryptography suitable for privacy-sensitive applications, such as whistleblowing platforms.

  [![build workflow](https://github.com/globaleaks/globaleaks-ephemeral-fs/actions/workflows/test.yml/badge.svg?branch=main)](https://github.com/globaleaks/globaleaks-whistleblowing-ephemeral-fs/actions/workflows/test.yml?query=branch%3Amain) [![Codacy Badge](https://app.codacy.com/project/badge/Grade/a2baab179e2141648621eeed4665fdeb)](https://app.codacy.com/gh/globaleaks/globaleaks-ephemeral-fs/dashboard?utm_source=gh&utm_medium=referral&utm_content=&utm_campaign=Badge_grade) [![Codacy Badge](https://app.codacy.com/project/badge/Coverage/a2baab179e2141648621eeed4665fdeb)](https://app.codacy.com/gh/globaleaks/globaleaks-ephemeral-fs/dashboard?utm_source=gh&utm_medium=referral&utm_content=&utm_campaign=Badge_coverage) [![PyPI - Downloads](https://img.shields.io/pypi/dm/globaleaks-ephemeral-fs)](https://pypi.org/project/globaleaks-ephemeral-fs/)


  `globaleaks-ephemeral-fs` provides an ephemeral, ChaCha20-encrypted filesystem implementation using Python, FUSE, and Cryptography. This filesystem is designed for temporary, secure storage with strong encryption, making it ideal for privacy-sensitive applications like whistleblowing platforms.



  To install the package, use `pip`:

  ```bash
  pip install globaleaks-ephemeral-fs
  ```





  To mount the filesystem from the command line:

  ```bash
  globaleaks-ephemeral-fs <mountpoint> [--storage_directory <directory>]
  ```

  - `<mountpoint>`: The path where the filesystem will be mounted.
  - `--storage_directory` (optional): The directory used for storage. If not provided, a temporary directory will be used.



  You can also use `globaleaks-ephemeral-fs` within your Python code. Here's an example:

  ```python
  import argparse
  from globaleaks_ephemeral_fs.ephemeral_fs import EphemeralFS

  def main():
      parser = argparse.ArgumentParser(description="Globaleaks Ephemeral FS")
      parser.add_argument('mount_point', help="Path to mount the filesystem")
      parser.add_argument('--storage_directory', '-s', help="Optional storage directory. Defaults to a temporary directory.")
      args = parser.parse_args()

      
      EphemeralFS(args.mount_point, args.storage_directory, nothreads=True, foreground=True)

  if __name__ == '__main__':
      main()
  ```



  - `mount_point` (required): The directory where the encrypted filesystem will be mounted.
  - `--storage_directory` (optional): Specify a custom storage directory for the filesystem. If not provided, a temporary directory will be used.



  - **ChaCha20 Encryption**: All data stored in the filesystem is encrypted with ChaCha20.
  - **FUSE Integration**: Mount the filesystem as a virtual disk using FUSE.
  - **Temporary Storage**: The filesystem is ephemeral and can use a temporary directory for storage.



  - Python 3.7+
  - `fusepy` for FUSE support
  - `cryptography` for encryption



  This project is licensed under the AGPLv3 License - see the [LICENSE](LICENSE) file for details.


pkgId: e5e6fc100fe35682b5f0668c330ba3c2d69dfef6859002cd0bd41d577053bf2b
name: python-gluestick-help
arch: noarch
version: 2.2.1
epoch: 0
release: 1
summary: Development documents and examples for gluestick
url: https://github.com/hotgluexyz/gluestick
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gluestick-2.2.1-1.src.rpm
location_href: Packages/python-gluestick-help-2.2.1-1.noarch.rpm
checksum_type: sha256
description:
  A small Python module containing quick utility functions for standard ETL processes.

  ```
  pip install gluestick
  ```

  * [Source]
  * [Wiki]
  * [Issues]
  * [Slack]

  [MIT]

  * NumPy
  * Pandas

  This project is maintained by the [hotglue] team. We welcome contributions from the
  community via issues and pull requests.
  If you wish to chat with our team, feel free to join our [Slack]!
  [Source]: https://github.com/hotgluexyz/gluestick
  [Wiki]: https://github.com/hotgluexyz/gluestick/wiki
  [Issues]: https://github.com/hotgluexyz/gluestick/issues
  [MIT]: https://tldrlegal.com/license/mit-license
  [hotglue]: https://hotglue.xyz
  [Slack]: https://bit.ly/2KBGGq1


pkgId: 66967f3ecacd2ac3fb8161b07e5c05c8410d30a58f048c066d1b4eae465b9dad
name: python-gmcapsule-help
arch: noarch
version: 0.9.5
epoch: 0
release: 1
summary: Development documents and examples for gmcapsule
url: https://pypi.org/project/gmcapsule/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gmcapsule-0.9.5-1.src.rpm
location_href: Packages/python-gmcapsule-help-0.9.5-1.noarch.rpm
checksum_type: sha256
description:
  GmCapsule is an extensible server for [Gemini](https://gemini.circumlunar.space/) and [Titan](https://transjovian.org/titan/).

  See the [User manual](https://geminispace.org/gmcapsule/gmcapsule.html) for configuration and usage instructions.



  Install "gmcapsule" via `pip`:

      pip install gmcapsule

  Then run the server daemon:

      gmcapsuled



  Create the following service file and save it as _~/.config/systemd/user/gmcapsule.service_:

      [Unit]
      Description=GmCapsule: extensible Gemini/Titan server
      After=network.target

      [Service]
      Type=simple
      ExecStart=<YOUR-INSTALL-PATH>/gmcapsuled
      ExecReload=/bin/kill -HUP $MAINPID
      Restart=always
      Environment="PYTHONUNBUFFERED=1"
      StandardOutput=syslog
      StandardError=syslog
      SyslogIdentifier=gmcapsule

      [Install]
      WantedBy=default.target

  Replace `<YOUR-INSTALL-PATH>` with the actual path of `gmcapsuled`. `pip` will install it in a directory on your PATH.

  Then you can do the usual:

      systemctl --user daemon-reload
      systemctl --user enable gmcapsule
      systemctl --user start gmcapsule

  The log can be viewed via journalctl (or syslog):

      journalctl -xe --user-unit=gmcapsule





  * Misfin: Added extension for receiving Misfin(B) and Misfin(C) messages and forwarding them to the configured email address(es).

  v0.9.1:

  * Certificates for virtual hosts are first checked under subdirectories in the certificate directory. The subdirectory name must match the virtual host domain name; the certificate files must be named "cert.pem" and "key.pem" in each subdirectory. As a fallback, every virtual host still uses the common certificate as before.

  v0.9.2:

  * Cleanup and minor fixes.

  v0.9.3:

  * Titan: Fixed parsing parameters when request contains a query string.

  v0.9.4:

  * Misfin: Fixed issue parsing sender certificate.

  v0.9.5:

  * Misfin: Updated URI format.
  * Documented more settings.



  * Added support for the Titan "edit" parameter. The `Request` class has a new `is_titan_edit` flag to indicate when a request is being processed as an edit.
  * Fixed handling of invalid Titan requests (unrecognized parameters or no size specified).
  * Fixed issue handling SIGHUP (patch by noirscape).



  * CGI: Fixed contents of `PATH_INFO`: it is now URL-decoded and the script path is removed so only the part following the script path is included in the environment variable (RFC 3875, section 4.1.5).
  * CGI: `bin_root` applies a wildcard to all found CGI executables so `PATH_INFO` can be used.
  * CGI: `bin_root` looks for executable "index.gmi" files in requested directories to provide the directory index.
  * Skip the TLS SNI check when request hostname has a literal IP address. (SNI is not supposed to be used with literal addresses.)
  * Respond with status 53 if an unknown hostname is requested. This helps reveal configuration errors where the correct hostnames are not specified.



  * Added `stream` to the `[cgi.*]` section to enable streaming output mode where the output of the CGI child process is immediately sent to the client without any buffering. Streaming is not supported if the server is using multiple processes.
  * Markdown: Fixed handling of alt text in preformatted blocks (patch by Mike Cifelli).

  v0.6.1:

  * Static: Fixed unquoting URL paths when looking up files.
  * Added example of printing Gemini meta line in CGI documentation.



  * Added `processes` to the `[server]` section to configure how many request handler processes are started.
  * Extension modules can register new protocols in addition to the built-in Gemini and Titan.
  * SIGHUP causes the configuration file to be reloaded and workers to be restarted. The listening socket remains open, so the socket and TLS parameters cannot be changed.
  * API change: Extension modules get initialized separately in each worker thread. Instead of a `Capsule`, the extension module `init` method is passed a `Context`. `Capsule` is no longer available as global state.
  * API change: `Identity` no longer contains OpenSSL objects for the certificate and public key. Instead, they are provided as serialized in DER format.

  v0.5.1:

  * `Identity` class is available when importing the `gmcapsule` module.

  v0.5.2:

  * Fixed error in the "rewrite" module (Codeberg PR #1).

  v0.5.3:

  * Enable address reuse on the server socket for unimpeded restarting (Codeberg PR #3).



  * Added built-in module "rewrite" that matches regular expressions against the request path and can rewrite the path or return a custom status for redirection, "Gone" messages, or other exceptional situations.
  * Extension module load order is determined after locating all modules from all directories. Previously, the order was local to each directory.
  * Added a new configuration section `[priority]` for overriding default module priorities determined from file names. This is useful for changing the priority of the built-in modules.

  v0.4.1:

  * Rewrite: Request query string can be included in a `status` using the `${QUERY_STRING}` variable.



  * Added a shutdown event for custom background workers.
  * `Request.query` is None if there is no query string present. Previously, the query string was an empty string in this case. This allows making a distinction between empty and absent query strings.

  v0.3.1:

  * CGI: Fixed handling of a missing query string.

  v0.3.2:

  * GitView: Fixed processing of Git commit history when a message contains backslashes.



  * Added `[cgi] bin_root` configuration option for automatically and dynamically mapping all executables in a directory tree to URL entry points.
  * Minor documentation updates.
  * Published on PyPi as "gmcapsule".

  v0.2.1:

  * Fixed error handling. Exceptions are now caught and the error message is printed.

  v0.2.2:

  * Reduced required Python version to 3.6 (f-strings).
  * Added systemd instructions.

  v0.2.3:

  * Requests exceeding 1024 bytes should result in an error code and not just be ignored.
  * Respond with an error code to malformed UTF-8 in the request.
  * Verify that the port number in the request URI matches the server's port.

  v0.2.4:

  * Fixed an error in the Markdown parser.

  v0.2.5:

  * Fixed handling of exceptions from request handler, and print a traceback.
  * Fixed `importlib` error with Python 3.11.



  * Initial public release.


pkgId: 567bdf5bbb01893a69f8b18ef1d0fbd7a9bc8b025272526509ce0648c1870e4b
name: python-gme-help
arch: noarch
version: 1.3.1
epoch: 0
release: 1
summary: Development documents and examples for gme
url: https://usitc-gravity-group.github.io/GME/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gme-1.3.1-1.src.rpm
location_href: Packages/python-gme-help-1.3.1-1.noarch.rpm
checksum_type: sha256
description:
  The GME package was created by the Gravity Modeling Group at the United States International Trade Commission. The package has been primarily developed by Peter Herman and Saad Ahmad. Additional contributions have been made by Serge Shikher, Tamara Gurevich, Samantha Schreiber, Carlos Payan, Caroline Peters, Grace Kenneally, and Austin Drenski.

  Contact us at [gravity@usitc.gov](mailto://gravity@usitc.gov?subject=[GME package])

  Additional information about the development team can be located at the project website at [gravity.usitc.gov](https://gravity.usitc.gov).


  Documentation for the package can be found at [https://usitc-gravity-group.github.io/GME/](https://usitc-gravity-group.github.io/GME/).



  GME is free, open-source software

  *Version:* 1.3


pkgId: 4084841c9e169240a21491a7dad5a8d0e011073152cec96015a725abdac25be7
name: python-gmmx-help
arch: noarch
version: 0.2
epoch: 0
release: 1
summary: Development documents and examples for gmmx
url: https://adonath.github.io/software#gmmx
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gmmx-0.2-1.src.rpm
location_href: Packages/python-gmmx-help-0.2-1.noarch.rpm
checksum_type: sha256
description:
  [![Release](https://img.shields.io/github/v/release/adonath/gmmx)](https://img.shields.io/github/v/release/adonath/gmmx)
  [![Build status](https://img.shields.io/github/actions/workflow/status/adonath/gmmx/main.yml?branch=main)](https://github.com/adonath/gmmx/actions/workflows/main.yml?query=branch%3Amain)
  [![codecov](https://codecov.io/gh/adonath/gmmx/branch/main/graph/badge.svg)](https://codecov.io/gh/adonath/gmmx)
  [![Commit activity](https://img.shields.io/github/commit-activity/m/adonath/gmmx)](https://img.shields.io/github/commit-activity/m/adonath/gmmx)
  [![License](https://img.shields.io/github/license/adonath/gmmx)](https://img.shields.io/github/license/adonath/gmmx)
  [![DOI](https://zenodo.org/badge/879790145.svg)](https://doi.org/10.5281/zenodo.14515326)

  <p align="center">
  <img width="50%" src="https://raw.githubusercontent.com/adonath/gmmx/main/docs/_static/gmmx-logo.png" alt="GMMX Logo"/>
  </p>

  A minimal implementation of Gaussian Mixture Models in Jax

  - **Github repository**: <https://github.com/adonath/gmmx/>
  - **Documentation** <https://adonath.github.io/gmmx/>



  `gmmx` can be installed via pip:

  ```bash
  pip install gmmx
  ```



  ```python
  from gmmx import GaussianMixtureModelJax, EMFitter


  gmm = GaussianMixtureModelJax.create(n_components=16, n_features=32)


  n_samples = 10_000
  x = gmm.sample(n_samples)


  em_fitter = EMFitter(tol=1e-3, max_iter=100)
  gmm_fitted = em_fitter.fit(x=x, gmm=gmm)
  ```

  If you use the code in a scientific publication, please cite the Zenodo DOI from the badge above.



  What are Gaussian Mixture Models (GMM) useful for in the age of deep learning? GMMs might have come out of fashion for classification tasks, but they still
  have a few properties that make them useful in certain scenarios:

  - They are universal approximators, meaning that given enough components they can approximate any distribution.
  - Their likelihood can be evaluated in closed form, which makes them useful for generative modeling.
  - They are rather fast to train and evaluate.

  I would strongly recommend to read [In Depth: Gaussian Mixture Models](https://jakevdp.github.io/PythonDataScienceHandbook/05.12-gaussian-mixtures.html) from the Python Data Science Handbook for a more in-depth introduction to GMMs and their
  application as density estimators.

  One of these applications in my research is the context of image reconstruction, where GMMs can be used to model the distribution and pixel correlations of local (patch based)
  image features. This can be useful for tasks like image denoising or inpainting. One of these methods I have used them for is [Jolideco](https://github.com/jolideco/jolideco).
  Speed up the training of O(10^6) patches was the main motivation for `gmmx`.



  Here are some results from the benchmarks in the [examples/benchmarks](https://github.com/adonath/gmmx/tree/main/examples/benchmarks) folder comparing against Scikit-Learn. The benchmarks were run on a 2021 MacBook Pro with an M1 Pro chip.



  | Time vs. Number of Components                                                                                                       | Time vs. Number of Samples                                                                                                    | Time vs. Number of Features                                                                                                     |
  | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
  | ![Time vs. Number of Components](https://raw.githubusercontent.com/adonath/gmmx/main/docs/_static/time-vs-n-components-predict.png) | ![Time vs. Number of Samples](https://raw.githubusercontent.com/adonath/gmmx/main/docs/_static/time-vs-n-samples-predict.png) | ![Time vs. Number of Features](https://raw.githubusercontent.com/adonath/gmmx/main/docs/_static/time-vs-n-features-predict.png) |

  For prediction the speedup is around 2x for varying number of components and features. For the number of samples the cross-over point is around O(10^4) samples.



  | Time vs. Number of Components                                                                                                   | Time vs. Number of Samples                                                                                                | Time vs. Number of Features                                                                                                 |
  | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
  | ![Time vs. Number of Components](https://raw.githubusercontent.com/adonath/gmmx/main/docs/_static/time-vs-n-components-fit.png) | ![Time vs. Number of Samples](https://raw.githubusercontent.com/adonath/gmmx/main/docs/_static/time-vs-n-samples-fit.png) | ![Time vs. Number of Features](https://raw.githubusercontent.com/adonath/gmmx/main/docs/_static/time-vs-n-features-fit.png) |

  For training the speedup is around 10x on the same architecture. However there is no guarantee that it will converge to the same solution as Scikit-Learn. But there are some tests in the `tests` folder that compare the results of the two implementations.


pkgId: 826a7ab8bb7c15cf7e7b72c7ba6996eab06ab2ffe96da3cf253ace69cd91b74d
name: python-gnetclisdk-help
arch: noarch
version: 1.0.49
epoch: 0
release: 1
summary: Development documents and examples for gnetclisdk
url: https://github.com/annetutil/gnetcli
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gnetclisdk-1.0.49-1.src.rpm
location_href: Packages/python-gnetclisdk-help-1.0.49-1.noarch.rpm
checksum_type: sha256
description:
  Gnetcli provides a universal way to execute arbitrary commands using a CLI,
  eliminating the need for screen scraping with expect.

  See documentation on [gnetcli server](https://annetutil.github.io/gnetcli/).

  Example:

  ```python
  from gnetclisdk.client import Credentials, Gnetcli
  import os, asyncio

  async def example():
      api = Gnetcli(insecure_grpc=True)
      dev_creds = Credentials(os.environ.get("LOGIN"), os.environ.get("PASSWORD"))
      res = await api.cmd(hostname="myhost", device="huawei", cmd="dis clock", credentials=dev_creds)
      print("err=%s status=%s out=%s" % (res.error, res.status, res.out))

  asyncio.run(example())
  ```

  Output:
  ```
  err=b'' status=0 out=b'2023-11-10 09:31:58\nFriday\nTime Zone(UTC) : UTC'
  ```


pkgId: e5d171939d50d5fe86a01ebff51f1eee6fbc413cfd05a0a75e5e4d009444b80a
name: python-gnmi-pb-help
arch: noarch
version: 0.11.0.0
epoch: 0
release: 1
summary: Development documents and examples for gnmi-pb
url: https://pypi.org/project/gnmi-pb/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gnmi-pb-0.11.0.0-1.src.rpm
location_href: Packages/python-gnmi-pb-help-0.11.0.0-1.noarch.rpm
checksum_type: sha256
description:
  This project was created to provide an easily installable python package
  of the GNMI protobuffer module (gnmi_pb).

  This is **not** an official build. For the official GNMI sources, see:

  https://github.com/openconfig/gnmi



  Install from pypi, e.g.:

  ```
  pip install gnmi_pb
  ```

  Import the gnmi protobuf submodules from the `gnmi_pb` module:

  ```
  >>> from gnmi_pb import gnmi_pb2, gnmi_pb2_grpc

  >>> gnmi_pb2.GetRequest(...)
  ```



  Our release version numbers follow the official GNMI versions but add a 4th number that reflects build-related changes.

  This project aims to build from .proto files as close as possible to the original ones, but some changes may be required to fix build issues.

  When the official proto sources are modified, it is mentioned it in the Changelog below.






  - protos from official GNMI v0.11.0 . Modified imports ([50e1d47](https://github.com/iPronics/gnmi-pb/commit/50e1d473bc14a4fb218db51bb7dd1594987c61a9))
  - project skeleton and metadata
  - `build.sh` for automated generation of python and type files and distribution creation
  - CI workflow for publishing python distribution in PyPI


pkgId: ae3b8eb72cb94c8cc39b4cea5e1a913f762e221224132fe7409561160fce9900
name: python-gnomonicus-help
arch: noarch
version: 3.0.5
epoch: 0
release: 1
summary: Development documents and examples for gnomonicus
url: https://github.com/oxfordmmm/gnomonicus
rpm_license: University of Oxford License, see LICENSE
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gnomonicus-3.0.5-1.src.rpm
location_href: Packages/python-gnomonicus-help-3.0.5-1.noarch.rpm
checksum_type: sha256
description:
  [![Tests](https://github.com/oxfordmmm/gnomonicus/actions/workflows/tests.yaml/badge.svg)](https://github.com/oxfordmmm/gnomonicus/actions/workflows/tests.yaml)
  [![Build and release Docker](https://github.com/oxfordmmm/gnomonicus/actions/workflows/build.yaml/badge.svg)](https://github.com/oxfordmmm/gnomonicus/actions/workflows/build.yaml)
  [![PyPI version](https://badge.fury.io/py/gnomonicus.svg)](https://badge.fury.io/py/gnomonicus)
  [![Docs](https://github.com/oxfordmmm/gnomonicus/actions/workflows/docs.yaml/badge.svg)](https://oxfordmmm.github.io/gnomonicus/)


  Python code to integrate results of tb-pipeline and provide an antibiogram, mutations and variations

  Provides a library of functions for use within scripts, as well as a CLI tool for linking the functions together to produce output


  API reference for developers, and CLI instructions can be found here: https://oxfordmmm.github.io/gnomonicus/

  ```
  usage: gnomonicus [-h] [-v] --vcf_file VCF_FILE --genome_object GENOME_OBJECT [--catalogue_file CATALOGUE_FILE] [--ignore_vcf_filter] [--output_dir OUTPUT_DIR] [--json] [--csvs CSVS [CSVS ...]] [--debug]
                    [--resistance_genes] --min_dp MIN_DP

  options:
    -h, --help            show this help message and exit
    -v, --version         show program's version number and exit
    --vcf_file VCF_FILE   the path to a single VCF file
    --genome_object GENOME_OBJECT
                          the path to a genbank file
    --catalogue_file CATALOGUE_FILE
                          the path to the resistance catalogue
    --ignore_vcf_filter   whether to ignore the FILTER field in the vcf (e.g. necessary for some versions of Clockwork VCFs)
    --output_dir OUTPUT_DIR
                          Directory to save output files to. Defaults to wherever the script is run from.
    --json                Flag to create a single JSON output as well as the CSVs
    --csvs CSVS [CSVS ...]
                          Types of CSV to produce. Accepted values are [variants, mutations, effects, predictions, all]. `all` produces all of the CSVs
    --debug               Whether to log debugging messages to the log. Defaults to False
    --resistance_genes    Flag to filter mutations and variants to only include genes present in the resistance catalogue
    --min_dp MIN_DP       Minimum depth for a variant to be considered in the VCF. Below this value, rows are interpreted as null calls.
  ```


  Simple install using pip for the latest release
  ```
  pip install gnomonicus
  ```

  Install from source
  ```
  git clone https://github.com/oxfordmmm/gnomonicus.git
  cd gnomonicus
  pip install -e .
  ```


  A Docker image should be built on releases. To open a shell with gnomonicus installed:
  ```
  docker run -it oxfordmmm/gnomonicus:latest
  ```


  When generating mutations, in cases of synonymous amino acid mutation, the nucelotides changed are also included. This can lead to a mix of nucleotides and amino acids for coding genes, but these are excluded from generating effects unless specified in the catalogue. This means that the default rule of `gene@*= --> S` is still in place regardless of the introduced `gene@*?` which would otherwise take precedence. For example:
  ```
    'MUTATIONS': [
        {
            'MUTATION': 'F2F',
            'GENE': 'S',
            'GENE_POSITION': 2
        },
        {
            'MUTATION': 't6c',
            'GENE': 'S',
            'GENE_POSITION': 6
        },
    ],
    'EFFECTS': {
        'AAA': [
            {
                'GENE': 'S',
                'MUTATION': 'F2F',
                'PREDICTION': 'S'
            },
            {
                'PHENOTYPE': 'S'
            }
        ],
    }
  ```
  The nucelotide variation is included in the the `MUTATIONS`, but explictly removed from the `EFFECTS` unless it is specified within the catalogue.
  In order for this variation to be included, a line in the catalogue of `S@F2F&S@t6c` would have to be present.



  1. As a bioinformatician, I want to be able to run `gnomonicus` on the command line, passing it (i) a GenBank file ~~(or pickled `gumpy.Genome` object)~~, (ii) a resistance catalogue and (iii) a VCF file, and get back `pandas.DataFrames` of the genetic variants, mutations, effects and predictions/antibiogram. The latter is for all the drugs described in the passed resistance catalogue.

  2. As a GPAS developer, I want to be able to embed `gnomonicus` in a Docker image/NextFlow pipeline that consumes the outputs of [tb-pipeline](https://github.com/Pathogen-Genomics-Cymru/tb-pipeline) and emits a structured, well-designed `JSON` object describing the genetic variants, mutations, effects and predictions/antibiogram.

  3. In general, I would also like the option to output fixed- and variable-length FASTA files (the latter takes into account insertions and deletions described in any input VCF file).



  For speed, rather than use NC_000962.3 (i.e. H37Rv *M. tuberculosis*), we shall use SARS-CoV-2 and have created a fictious drug resistance catalogue, along with some `vcf` files and the expected outputs in `tests/`.

  These can be run with `pytest -vv`


pkgId: de6b12749b7401235f13903a62f8d868439d1d8c7f048015efc12173fcdb6e6f
name: python-gnvext-help
arch: noarch
version: 0.0.1
epoch: 0
release: 1
summary: Development documents and examples for gnvext
url: https://pypi.org/project/gnvext/
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gnvext-0.0.1-1.src.rpm
location_href: Packages/python-gnvext-help-0.0.1-1.noarch.rpm
checksum_type: sha256
description:
  Wrapper for converting environment variables to any python type

  <br>


  **Python 3.10+ is required**

  > [!NOTE]
  > It's recommended to activate <a href="https://docs.python.org/3/library/venv.html">Virtual Environment</a> before installing dext

  To clone and install required packages use the following command:
  ```bash
  $ python3 -m pip install gnvext
  ```

  Also, dext may be cloned from GitHub:
  ```bash
  $ git clone https://github.com/DouleLove/gnvext
  ```

  <br>


  ```py
  import gnvext
  import django





  ALLOWED_HOSTS = dext.CollectionEnvVariable(
      'DJANGO_ALLOWED_HOSTS',
      ['*'],
  ).value

  ...  # django project settings.py stuff here
  ```

rpm_license:
  The MIT License (MIT)  Copyright (c) 2024-present DouleLove  Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:  The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


pkgId: b4d71ddc46cdb16849e0c2cc993a46f5c8590ee83cf8167dee8383649fce7ff8
name: python-gofigr-help
arch: noarch
version: 0.18.0
epoch: 0
release: 1
summary: Development documents and examples for gofigr
url: https://www.gofigr.io
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gofigr-0.18.0-1.src.rpm
location_href: Packages/python-gofigr-help-0.18.0-1.noarch.rpm
checksum_type: sha256
description:
  GoFigr (https://www.gofigr.io) is a service which provides sophisticated version control for figures.
  This repository contains the Python client for GoFigr.
  Account registration
  ********************
  Before you begin, create an account at https://app.gofigr.io/register
  Client setup
  *************
  First, install the ``gofigr`` client library:
      $ pip install gofigr
  Once installed, configure it with ``gfconfig``. The tool will prompt you for a
  username and password, and a default workspace.

rpm_license:
  Copyright 2022-2024 Flagstaff Solutions, LLC  Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:  The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.  THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


pkgId: bc5cca3aac8838c7b28ecb5a9ecc1b39b355494dc053d10dfcf0b1cea4713058
name: python-goodfire-help
arch: noarch
version: 0.2.40
epoch: 0
release: 1
summary: Development documents and examples for goodfire
url: https://pypi.org/project/goodfire/
rpm_license: Apache-2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-goodfire-0.2.40-1.src.rpm
location_href: Packages/python-goodfire-help-0.2.40-1.noarch.rpm
checksum_type: sha256
description:
  Understanding and steering AI models!



  ```
  pip install goodfire
  ```

  See `examples/quickstart.ipynb`


pkgId: cbf14429ea53cf377fee641a9ef516ab34cc015af6f0dc3bbbc9cde4fd78266a
name: python-google-ai-haystack-help
arch: noarch
version: 4.0.1
epoch: 0
release: 1
summary: Development documents and examples for google-ai-haystack
url: https://pypi.org/project/google-ai-haystack/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-google-ai-haystack-4.0.1-1.src.rpm
location_href: Packages/python-google-ai-haystack-help-4.0.1-1.noarch.rpm
checksum_type: sha256
description:
  **Table of Contents**
  - [Installation](#installation)
  - [License](#license)

  ```console
  pip install google-ai-haystack
  ```

  `google-ai-haystack` is distributed under the terms of the [Apache-2.0](https://spdx.org/licenses/Apache-2.0.html) license.


pkgId: 63a54aee792b89ad029f79ca3bbff035620424b66d7e5738c37b5f98d8a5ec8c
name: python-google-api-python-client-help
arch: noarch
version: 2.156.0
epoch: 0
release: 1
summary: Development documents and examples for google-api-python-client
url: https://github.com/googleapis/google-api-python-client/
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-google-api-python-client-2.156.0-1.src.rpm
location_href: Packages/python-google-api-python-client-help-2.156.0-1.noarch.rpm
checksum_type: sha256
description:
  [![PyPI version](https://badge.fury.io/py/google-api-python-client.svg)](https://badge.fury.io/py/google-api-python-client)

  This is the [Google API Python client library](https://cloud.google.com/apis/docs/client-libraries-explained#google_api_client_libraries)
  for Google's discovery based APIs. To get started, please see the
  [docs folder](https://github.com/googleapis/google-api-python-client/blob/main/docs/README.md).

  This library is considered complete and is in maintenance mode. This means
  that we will address critical bugs and security issues but will not add any
  new features.

  This library is officially supported by Google.  However, the maintainers of
  this repository recommend using [Cloud Client Libraries for Python](https://github.com/googleapis/google-cloud-python),
  where possible, for new code development. For more information, please visit
  [Client Libraries Explained](https://cloud.google.com/apis/docs/client-libraries-explained).


  The 2.0 release of `google-api-python-client` includes a substantial reliability
  improvement, compared with 1.x, as discovery documents are now cached in the library
  rather than fetched dynamically. It is highly recommended to upgrade from v1.x to v2.x.

  Only python 3.7 and newer is supported. If you are not able to upgrade python, then
  please continue to use version 1.x as we will continue supporting python 2.7+ in
  [v1](https://github.com/googleapis/google-api-python-client/tree/v1).

  Discovery documents will no longer be retrieved dynamically when
  you call `discovery.build()`. The discovery documents will instead be retrieved
  from the client library directly. New versions of this library are released weekly.
  As a result of caching the discovery documents, the size of this package is at least
  50 MB larger compared to the previous version.

  Please see the [Migration Guide](https://github.com/googleapis/google-api-python-client/blob/main/UPGRADING.md)
  for more information.



  See the [docs folder](https://github.com/googleapis/google-api-python-client/blob/main/docs/README.md) for more detailed instructions and additional documentation.



  The maintainers of this repository recommend using
  [Cloud Client Libraries for Python](https://github.com/googleapis/google-cloud-python),
  where possible, for new code development due to the following reasons:

  With [Cloud Client Libraries for Python](https://github.com/googleapis/google-cloud-python):
  - There is a separate client library for each API, so you can choose
  which client libraries to download. Whereas, `google-api-python-client` is a
  single client library for all APIs. As a result, the total package size for
  `google-api-python-client` exceeds 50MB.
  - There are stricter controls for breaking changes to the underlying APIs
  as each client library is focused on a specific API.
  - There are more features in these Cloud Client Libraries as each library is
  focused on a specific API, and in some cases, the libraries are owned by team
  who specialized in that API.
  - Developers will benefit from intellisense.

  For more information, please visit
  [Client Libraries Explained](https://cloud.google.com/apis/docs/client-libraries-explained).

  Although there are many benefits to moving to
  [Cloud Client Libraries for Python](https://github.com/googleapis/google-cloud-python),
  the maintainers want to emphasize that `google-api-python-client` will continue
  to be supported.

  For Google Ads API, we recommend using [Google Ads API Client Library for Python](https://github.com/googleads/google-ads-python/).

  For Google Firebase Admin API, we recommend using [Firebase Admin Python SDK](https://github.com/firebase/firebase-admin-python).



  Install this library in a [virtualenv](https://virtualenv.pypa.io/en/latest/) using pip. virtualenv is a tool to
  create isolated Python environments. The basic problem it addresses is one of
  dependencies and versions, and indirectly permissions.

  With virtualenv, it's possible to install this library without needing system
  install permissions, and without clashing with the installed system
  dependencies.



  ```bash
  pip3 install virtualenv
  virtualenv <your-env>
  source <your-env>/bin/activate
  <your-env>/bin/pip install google-api-python-client
  ```



  ```batch
  pip install virtualenv
  virtualenv <your-env>
  <your-env>\Scripts\activate
  <your-env>\Scripts\pip.exe install google-api-python-client
  ```



  Python 3.7, 3.8, 3.9, 3.10, 3.11 and 3.12 are fully supported and tested. This library may work on later versions of 3, but we do not currently run tests against those versions.



  Python < 3.7



  The following libraries will be installed when you install the client library:
  * [httplib2](https://github.com/httplib2/httplib2)
  * [uritemplate](https://github.com/sigmavirus24/uritemplate)

  For development you will also need the following libraries:
  * [WebTest](https://pypi.org/project/WebTest/)
  * [pyopenssl](https://pypi.python.org/pypi/pyOpenSSL)



  Please see our [Contribution Guide](https://github.com/googleapis/google-api-python-client/blob/main/CONTRIBUTING.rst).
  In particular, we love pull requests - but please make sure to sign
  the contributor license agreement.


pkgId: c8c2859416bafb8e572d1f67945b1c94fcc7d7f81a0b095cbde2f09317adc68e
name: python-google-cloud-contact-center-insights-help
arch: noarch
version: 1.22.0
epoch: 0
release: 1
summary: Development documents and examples for google-cloud-contact-center-insights
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-google-cloud-contact-center-insights-1.22.0-1.src.rpm
location_href: Packages/python-google-cloud-contact-center-insights-help-1.22.0-1.noarch.rpm
checksum_type: sha256
description:
  |stable| |pypi| |versions|
  `Contact Center AI Insights`_:  helps users detect and visualize patterns in their contact center data.
  - `Client Library Documentation`_
  - `Product Documentation`_

url:
  https://github.com/googleapis/google-cloud-python/tree/main/packages/google-cloud-contact-center-insights


pkgId: 7c845f5b920ec60f997c23b10d853b67466801ae6c491cc818a3a3af6f176d04
name: python-google-cloud-datacatalog-help
arch: noarch
version: 3.24.1
epoch: 0
release: 1
summary: Development documents and examples for google-cloud-datacatalog
url: https://github.com/googleapis/google-cloud-python/tree/main/packages/google-cloud-datacatalog
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-google-cloud-datacatalog-3.24.1-1.src.rpm
location_href: Packages/python-google-cloud-datacatalog-help-3.24.1-1.noarch.rpm
checksum_type: sha256
description:
  |stable| |pypi| |versions|
  `Google Cloud Data Catalog`_: is a fully managed and highly scalable data discovery and metadata management service.
  - `Client Library Documentation`_
  - `Product Documentation`_


pkgId: 489faf0b451ace2bda982aa548576c8c3964d342c360fa26c3ce11e01826a421
name: python-google-cloud-dialogflow-help
arch: noarch
version: 2.38.0
epoch: 0
release: 1
summary: Development documents and examples for google-cloud-dialogflow
url: https://github.com/googleapis/google-cloud-python/tree/main/packages/google-cloud-dialogflow
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-google-cloud-dialogflow-2.38.0-1.src.rpm
location_href: Packages/python-google-cloud-dialogflow-help-2.38.0-1.noarch.rpm
checksum_type: sha256
description:
  |stable| |pypi| |versions|
  `Dialogflow`_: is an end-to-end, build-once deploy-everywhere development suite for creating conversational interfaces for websites, mobile applications, popular messaging platforms, and IoT devices. You can use it to build interfaces (such as chatbots and conversational IVR) that enable natural and rich interactions between your users and your business. Dialogflow Enterprise Edition users have access to Google Cloud Support and a service level agreement (SLA) for production deployments.
  - `Client Library Documentation`_
  - `Product Documentation`_


pkgId: 51a22688161cb973545785c41f8924c612d1e8dc69f81ce9bc94d09d86812903
name: python-google-cloud-documentai-toolbox-help
arch: noarch
version: 0.14.1a0
epoch: 0
release: 1
summary: Development documents and examples for google-cloud-documentai-toolbox
url: https://github.com/googleapis/python-documentai-toolbox
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-google-cloud-documentai-toolbox-0.14.1a0-1.src.rpm
location_href: Packages/python-google-cloud-documentai-toolbox-help-0.14.1a0-1.noarch.rpm
checksum_type: sha256
description:
  |experimental| |versions|
  `Document AI Toolbox`_: Document AI Toolbox aims to reduce the friction of managing, manipulating, and extracting information from outputs of Document AI ``BatchProcessDocuments()`` (JSON files written to user-managed GCS buckets) and ``ProcessDocument()`` methods, programmatically.
  **Disclaimer**
  The Document AI Toolbox is in an experimental state. This library is a work-in-progress and is likely to have backwards-incompatible changes. Users of the toolbox might need to rewrite their code when upgrading the toolbox version.


pkgId: 69ff4aa36e710d06132c8a668bc21281c591fd8aaad4778c9f1d9615c3b20651
name: python-google-cloud-kms-help
arch: noarch
version: 3.2.1
epoch: 0
release: 1
summary: Development documents and examples for google-cloud-kms
url: https://github.com/googleapis/google-cloud-python/tree/main/packages/google-cloud-kms
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-google-cloud-kms-3.2.1-1.src.rpm
location_href: Packages/python-google-cloud-kms-help-3.2.1-1.noarch.rpm
checksum_type: sha256
description:
  |stable| |pypi| |versions|
  `Google Cloud Key Management Service`_: a cloud-hosted key management service that lets you manage cryptographic keys for your cloud services the same way you do on-premises. You can generate, use, rotate, and destroy AES256, RSA 2048, RSA 3072, RSA 4096, EC P256, and EC P384 cryptographic keys. Cloud KMS is integrated with Cloud IAM and Cloud Audit Logging so that you can manage permissions on individual keys and monitor how these are used. Use Cloud KMS to protect secrets and other sensitive data that you need to store in Google Cloud Platform.
  - `Client Library Documentation`_
  - `Product Documentation`_


pkgId: 86c311bd56d4bd0ce33f40e00091a04e99cd5f0f740d3fb92ae31b3bd4fc2ff6
name: python-google-cloud-storage-transfer-help
arch: noarch
version: 1.15.0
epoch: 0
release: 1
summary: Development documents and examples for google-cloud-storage-transfer
url: https://github.com/googleapis/google-cloud-python/tree/main/packages/google-cloud-storage-transfer
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-google-cloud-storage-transfer-1.15.0-1.src.rpm
location_href: Packages/python-google-cloud-storage-transfer-help-1.15.0-1.noarch.rpm
checksum_type: sha256
description:
  |stable| |pypi| |versions|
  `Storage Transfer Service`_: Secure, low-cost services for transferring data from cloud or on-premises sources.
  - `Client Library Documentation`_
  - `Product Documentation`_


pkgId: de567d490e9cf34ea675868f89bd730097cf66b7a4b21b88ade598cecfc75a95
name: python-google-cloud-testutils
arch: noarch
version: 1.5.0
epoch: 0
release: 1
summary: please add a summary manually as the author left a blank one
url: https://github.com/googleapis/python-test-utils
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-google-cloud-testutils-1.5.0-1.src.rpm
location_href: Packages/python-google-cloud-testutils-1.5.0-1.noarch.rpm
checksum_type: sha256
description:
  Python Test Utils


  This is a collection of common tools used in system tests of Python client libraries for Google APIs.

  We use `nox <https://nox.readthedocs.io/en/latest/>`__ to instrument our tests. This package is added to each `nox` session as described in each repository's ``noxfile.py``.


pkgId: 8ac8b9770fa78e54d9a50fdfb1efc40d219bb3f947c1ce774851032cf39df997
name: python-google-cloud-texttospeech-help
arch: noarch
version: 2.23.0
epoch: 0
release: 1
summary: Development documents and examples for google-cloud-texttospeech
url: https://github.com/googleapis/google-cloud-python/tree/main/packages/google-cloud-texttospeech
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-google-cloud-texttospeech-2.23.0-1.src.rpm
location_href: Packages/python-google-cloud-texttospeech-help-2.23.0-1.noarch.rpm
checksum_type: sha256
description:
  |stable| |pypi| |versions|
  `Google Cloud Text-to-Speech`_: enables easy integration of Google text recognition technologies into developer applications. Send text and receive synthesized audio output from the Cloud Text-to-Speech API service.
  - `Client Library Documentation`_
  - `Product Documentation`_


pkgId: 21c7f2c009161d7570222422d2f52538b83bfc09b18cb191b680077042684bc7
name: python-google-pso-data-validator-help
arch: noarch
version: 7.0.0
epoch: 0
release: 1
summary: Development documents and examples for google-pso-data-validator
url: https://pypi.org/project/google-pso-data-validator/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-google-pso-data-validator-7.0.0-1.src.rpm
location_href: Packages/python-google-pso-data-validator-help-7.0.0-1.noarch.rpm
checksum_type: sha256
description:
  The Data Validation Tool is an open sourced Python CLI tool based on the
  [Ibis framework](https://ibis-project.org/docs/)
  that compares heterogeneous data source tables with multi-leveled validation
  functions.

  Data validation is a critical step in a data warehouse, database, or data lake
  migration project where data from both the source and the target tables are
  compared to ensure they are matched and correct after each migration step
  (e.g. data and schema migration, SQL script translation, ETL migration, etc.).
  The Data Validation Tool (DVT) provides an automated and repeatable solution to
  perform this task.

  DVT supports the following validations:
  * Column validation (count, sum, avg, min, max, stddev, group by)
  * Row validation (Not supported for FileSystem connections)
  * Schema validation
  * Custom Query validation
  * Ad hoc SQL exploration

  DVT supports the following connection types:

  *   [AlloyDB](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md#alloydb)
  *   [BigQuery](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md#google-bigquery)
  *   [DB2](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md#db2)
  *   [FileSystem](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md#filesystem)
  *   [Hive](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md#hive)
  *   [Impala](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md#impala)
  *   [MSSQL](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md#mssql-server)
  *   [MySQL](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md#mysql)
  *   [Oracle](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md#oracle)
  *   [Postgres](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md#postgres)
  *   [Redshift](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md#redshift)
  *   [Spanner](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md#google-spanner)
  *   [Teradata](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md#teradata)
  *   [Snowflake](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md#snowflake)

  The [Connections](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md) page provides details about how to create
  and list connections for the validation tool.


  This is not an officially supported Google product. Please be aware that bugs may lurk, and that we reserve the right to make small backwards-incompatible changes. Feel free to open bugs or feature requests, or contribute directly
  (see [CONTRIBUTING.md](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/CONTRIBUTING.md) for details).



  The [Installation](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/installation.md) page describes the prerequisites and
  setup steps needed to install and use the Data Validation Tool.



  Before using this tool, you will need to create connections to the source and
  target tables. Once the connections are created, you can run validations on
  those tables. Validation results can be printed to stdout (default) or outputted
  to BigQuery (recommended). DVT also allows you to save and edit validation
  configurations in a YAML or JSON file. This is useful for running common validations or
  updating the configuration.



  Before running validations, DVT requires setting up a source and target connection.
  These connections can be stored locally or in a GCS directory. To create connections,
  please review the [Connections](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/connections.md) page.



  The CLI is the main interface to use this tool and it has several different
  commands which can be used to create and run validations. Below are the command
  syntax and options for running validations.

  Alternatives to running DVT in the CLI include deploying DVT to Cloud Run, Cloud Functions, or Airflow
  ([Examples Here](https://github.com/GoogleCloudPlatform/professional-services-data-validator/tree/develop/samples)). See the [Validation Logic](https://github.com/GoogleCloudPlatform/professional-services-data-validator#validation-logic) section
  to learn more about how DVT uses the CLI to generate SQL queries.

  Note that we do not support nested or complex columns for column or row validations.



  Below is the command syntax for column validations. To run a grouped column
  validation, simply specify the `--grouped-columns` flag.

  You can specify a list of string columns for aggregations in order to calculate
  an aggregation over the `length(string_col)`. Similarly, you can specify timestamp/date
  columns for aggregation over the `unix_seconds(timestamp_col)`. Running an aggregation
  over all columns ('*') will only run over numeric columns, unless the
  `--wildcard-include-string-len` or `--wildcard-include-timestamp` flags are present.

  ```
  data-validation
    [--verbose or -v ]
                          Verbose logging
    [--log-level or -ll]
                          Log Level to be assigned. Supported levels are (DEBUG,INFO,WARNING,ERROR,CRITICAL). Defaults to INFO.
    validate column
    --source-conn or -sc SOURCE_CONN
                          Source connection details
                          See: *Data Source Configurations* section for each data source
    --target-conn or -tc TARGET_CONN
                          Target connection details
                          See: *Connections* section for each data source
    --tables-list or -tbls SOURCE_SCHEMA.SOURCE_TABLE=TARGET_SCHEMA.TARGET_TABLE
                          Comma separated list of tables in the form schema.table=target_schema.target_table. Or shorthand schema.* for all tables.
                          Target schema name and table name are optional.
                          i.e 'bigquery-public-data.new_york_citibike.citibike_trips'
    [--grouped-columns or -gc GROUPED_COLUMNS]
                          Comma separated list of columns for Group By i.e col_a,col_b
    [--count COLUMNS]     Comma separated list of columns for count or * for all columns
    [--sum COLUMNS]       Comma separated list of columns for sum or * for all numeric
    [--min COLUMNS]       Comma separated list of columns for min or * for all numeric
    [--max COLUMNS]       Comma separated list of columns for max or * for all numeric
    [--avg COLUMNS]       Comma separated list of columns for avg or * for all numeric
    [--std COLUMNS]       Comma separated list of columns for stddev_samp or * for all numeric
    [--exclude-columns or -ec]
                          Flag to indicate the list of columns provided should be excluded and not included.
    [--bq-result-handler or -bqrh PROJECT_ID.DATASET.TABLE or CONNECTION_NAME.DATASET.TABLE]
                          BigQuery destination for validation results. Defaults to stdout.
                          See: *Validation Reports* section
    [--service-account or -sa PATH_TO_SA_KEY]
                          Service account to use for BigQuery result handler output.
    [--wildcard-include-string-len or -wis]
                          If flag is present, include string columns in aggregation as len(string_col)
    [--wildcard-include-timestamp or -wit]
                          If flag is present, include timestamp/date columns in aggregation as unix_seconds(ts_col)
    [--cast-to-bigint or -ctb]
                          If flag is present, cast all int32 columns to int64 before aggregation
    [--filters SOURCE_FILTER:TARGET_FILTER]
                          Colon separated string values of source and target filters.
                          If target filter is not provided, the source filter will run on source and target tables.
                          See: *Filters* section
    [--config-file or -c CONFIG_FILE]
                          YAML Config File Path to be used for storing validations and other features. Supports GCS and local paths.
                          See: *Running DVT with YAML Configuration Files* section
    [--config-file-json or -cj CONFIG_FILE_JSON]
                          JSON Config File Path to be used for storing validations only for application purposes.
    [--threshold or -th THRESHOLD]
                          Float value. Maximum pct_difference allowed for validation to be considered a success. Defaults to 0.0
    [--labels or -l KEY1=VALUE1,KEY2=VALUE2]
                          Comma-separated key value pair labels for the run.
    [--format or -fmt FORMAT]
                          Format for stdout output. Supported formats are (text, csv, json, table). Defaults to table.
    [--filter-status or -fs STATUSES_LIST]
                          Comma separated list of statuses to filter the validation results. Supported statuses are (success, fail). If no list is provided, all statuses are returned.

  ```

  The default aggregation type is a 'COUNT *', which will run in addition to the validations you specify. To remove this default,
  use [YAML configs](https://github.com/GoogleCloudPlatform/professional-services-data-validator/tree/develop#running-dvt-with-yaml-configuration-files).

  The [Examples](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/examples.md) page provides many examples of how a tool can be used to run powerful validations without writing any queries.



  (Note: Row hash validation not supported for FileSystem connections.
  In addition, please note that SHA256 is not a supported function on Teradata systems.
  If you wish to perform this comparison on Teradata you will need to
  [deploy a UDF to perform the conversion](https://github.com/akuroda/teradata-udf-sha2/blob/master/src/sha256.c).)

  Below is the command syntax for row validations. In order to run row level validations we require
  unique columns to join row sets, which are either inferred from the source/target table or provided
  via the `--primary-keys` flag, and either the `--hash`, `--concat` or `--comparison-fields` flags.
  See *Primary Keys* section.

  The `--comparison-fields` flag specifies the values (e.g. columns) whose raw values will be compared
  based on the primary key join. The `--hash` flag will run a checksum across specified columns in
  the table. This will include casting to string, sanitizing the data (ifnull, rtrim, upper), concatenating,
  and finally hashing the row.

  Under the hood, row validation uses
  [Calculated Fields](https://github.com/GoogleCloudPlatform/professional-services-data-validator#calculated-fields) to
  apply functions such as IFNULL() or RTRIM(). These can be edited in the YAML or JSON config file to customize your row validation.

  ```
  data-validation
    [--verbose or -v ]
                          Verbose logging
    [--log-level or -ll]
                          Log Level to be assigned. Supported levels are (DEBUG,INFO,WARNING,ERROR,CRITICAL). Defaults to INFO.
    validate row
    --source-conn or -sc SOURCE_CONN
                          Source connection details
                          See: *Data Source Configurations* section for each data source
    --target-conn or -tc TARGET_CONN
                          Target connection details
                          See: *Connections* section for each data source
    --tables-list or -tbls SOURCE_SCHEMA.SOURCE_TABLE=TARGET_SCHEMA.TARGET_TABLE
                          Comma separated list of tables in the form schema.table=target_schema.target_table
                          Target schema name and table name are optional.
                          i.e 'bigquery-public-data.new_york_citibike.citibike_trips'
    --comparison-fields or -comp-fields FIELDS
                          Comma separated list of columns to compare. Can either be a physical column or an alias
                          See: *Calculated Fields* section for details
    --hash COLUMNS        Comma separated list of columns to hash or * for all columns
    --concat COLUMNS      Comma separated list of columns to concatenate or * for all columns (use if a common hash function is not available between databases)
    [--primary-keys PRIMARY_KEYS, -pk PRIMARY_KEYS]
                          Comma separated list of primary key columns, when not specified the value will be inferred
                          from the source or target table if available.  See *Primary Keys* section
    [--exclude-columns or -ec]
                          Flag to indicate the list of columns provided should be excluded from hash or concat instead of included.
    [--bq-result-handler or -bqrh PROJECT_ID.DATASET.TABLE or CONNECTION_NAME.DATASET.TABLE]
                          BigQuery destination for validation results. Defaults to stdout.
                          See: *Validation Reports* section
    [--service-account or -sa PATH_TO_SA_KEY]
                          Service account to use for BigQuery result handler output.
    [--filters SOURCE_FILTER:TARGET_FILTER]
                          Colon separated string values of source and target filters.
                          If target filter is not provided, the source filter will run on source and target tables.
                          See: *Filters* section
    [--config-file or -c CONFIG_FILE]
                          YAML Config File Path to be used for storing validations and other features. Supports GCS and local paths.
                          See: *Running DVT with YAML Configuration Files* section
    [--config-file-json or -cj CONFIG_FILE_JSON]
                          JSON Config File Path to be used for storing validations only for application purposes.
    [--labels or -l KEY1=VALUE1,KEY2=VALUE2]
                          Comma-separated key value pair labels for the run.
    [--format or -fmt FORMAT]
                          Format for stdout output. Supported formats are (text, csv, json, table). Defaults to table.
    [--use-random-row or -rr]
                          Finds a set of random rows of the first primary key supplied.
    [--random-row-batch-size or -rbs]
                          Row batch size used for random row filters (default 10,000).
    [--filter-status or -fs STATUSES_LIST]
                          Comma separated list of statuses to filter the validation results. Supported statuses are (success, fail). If no list is provided, all statuses are returned.
    [--trim-string-pks, -tsp]
                          Trims string based primary key values, intended for use when one engine uses padded string semantics (e.g. CHAR(n)) and the other does not (e.g. VARCHAR(n)).
    [--case-insensitive-match, -cim]
                          Performs a case insensitive match by adding an UPPER() before comparison.
  ```


  When performing row validations, Data Validation Tool brings each row into memory and can run into MemoryError. Below is the command syntax for generating partitions in order to perform row validations on large dataset (table or custom-query) to alleviate MemoryError. Each partition contains a range of primary key(s) and the ranges of keys across partitions are distinct. The partitions have nearly equal number of rows. See *Primary Keys* section

  The command generates and stores multiple YAML validations each representing a chunk of the large dataset using filters (`WHERE primary_key(s) >= X AND primary_key(s) < Y`) in YAML files. The parameter parts-per-file, specifies the number of validations in one YAML file. Each yaml file will have parts-per-file validations in it - except the last one which will contain the remaining partitions (i.e. parts-per-file may not divide partition-num evenly). You can then run the validations in the directory serially (or in parallel in multiple containers, VMs) with the `data-validation configs run --config-dir PATH` command as described [here](https://github.com/GoogleCloudPlatform/professional-services-data-validator#yaml-configuration-files).

  The command takes the same parameters as required for `Row Validation` *plus* a few parameters to support partitioning. Single and multiple primary keys are supported and keys can be of any indexable type, except for date and timestamp type. You can specify tables that are being validated or the source and target custom query. A parameter used in earlier versions, ```partition-key``` is no longer supported.

  ```
  data-validation
    [--verbose or -v ]
                          Verbose logging
    [--log-level or -ll]
                          Log Level to be assigned. Supported levels are (DEBUG,INFO,WARNING,ERROR,CRITICAL). Defaults to INFO.
    generate-table-partitions
    --source-conn or -sc SOURCE_CONN
                          Source connection details
                          See: *Data Source Configurations* section for each data source
    --target-conn or -tc TARGET_CONN
                          Target connection details
                          See: *Connections* section for each data source
    --tables-list or -tbls SOURCE_SCHEMA.SOURCE_TABLE=TARGET_SCHEMA.TARGET_TABLE
                          Comma separated list of tables in the form schema.table=target_schema.target_table
                          Target schema name and table name are optional.
                          i.e 'bigquery-public-data.new_york_citibike.citibike_trips'
                          Either --tables-list or --source-query (or file) and --target-query (or file) must be provided
    --source-query SOURCE_QUERY, -sq SOURCE_QUERY
                          Source sql query
                          Either --tables-list or --source-query (or file) and --target-query (or file) must be provided
    --source-query-file  SOURCE_QUERY_FILE, -sqf SOURCE_QUERY_FILE
                          File containing the source sql command. Supports GCS and local paths.
    --target-query TARGET_QUERY, -tq TARGET_QUERY
                          Target sql query
                          Either --tables-list or --source-query (or file) and --target-query (or file) must be provided
    --target-query-file TARGET_QUERY_FILE, -tqf TARGET_QUERY_FILE
                          File containing the target sql command. Supports GCS and local paths.
    --comparison-fields or -comp-fields FIELDS
                          Comma separated list of columns to compare. Can either be a physical column or an alias
                          See: *Calculated Fields* section for details
    --hash COLUMNS        Comma separated list of columns to hash or * for all columns
    --concat COLUMNS      Comma separated list of columns to concatenate or * for all columns (use if a common hash function is not available between databases)
    --config-dir CONFIG_DIR, -cdir CONFIG_DIR
                          Directory Path to store YAML Config Files
                          GCS: Provide a full gs:// path of the target directory. Eg: `gs://<BUCKET>/partitions_dir`
                          Local: Provide a relative path of the target directory. Eg: `partitions_dir`
                          If invoked with -tbls parameter, the validations are stored in a directory named <schema>.<table>, otherwise the directory is named `custom.<random_string>`
    --partition-num INT, -pn INT
                          Number of partitions into which the table should be split, e.g. 1000 or 10000
                          In case this value exceeds the row count of the source/target table, it will be decreased to max(source_row_count, target_row_count)
    [--primary-keys PRIMARY_KEYS, -pk PRIMARY_KEYS]
                          Comma separated list of primary key columns, when not specified the value will be inferred
                          from the source or target table if available.  See *Primary Keys* section
    [--bq-result-handler or -bqrh PROJECT_ID.DATASET.TABLE or CONNECTION_NAME.DATASET.TABLE]
                          BigQuery destination for validation results. Defaults to stdout.
                          See: *Validation Reports* section
    [--service-account or -sa PATH_TO_SA_KEY]
                          Service account to use for BigQuery result handler output.
    [--parts-per-file INT], [-ppf INT]
                          Number of partitions in a yaml file, default value 1.
    [--filters SOURCE_FILTER:TARGET_FILTER]
                          Colon separated string values of source and target filters.
                          If target filter is not provided, the source filter will run on source and target tables.
                          See: *Filters* section
    [--labels or -l KEY1=VALUE1,KEY2=VALUE2]
                          Comma-separated key value pair labels for the run.
    [--format or -fmt FORMAT]
                          Format for stdout output. Supported formats are (text, csv, json, table). Defaults to table.
    [--filter-status or -fs STATUSES_LIST]
                          Comma separated list of statuses to filter the validation results. Supported statuses are (success, fail). If no list is provided, all statuses are returned.
    [--trim-string-pks, -tsp]
                          Trims string based primary key values, intended for use when one engine uses padded string semantics (e.g. CHAR(n)) and the other does not (e.g. VARCHAR(n)).
    [--case-insensitive-match, -cim]
                          Performs a case insensitive match by adding an UPPER() before comparison.
  ```


  Below is the syntax for schema validations. These can be used to compare case insensitive column names and
  types between source and target.

  Note: An exclamation point before a data type (`!string`) signifies the column is non-nullable or required.

  ```
  data-validation
    [--verbose or -v ]
                          Verbose logging
    [--log-level or -ll]
                          Log Level to be assigned. Supported levels are (DEBUG,INFO,WARNING,ERROR,CRITICAL). Defaults to INFO.
    validate schema
    --source-conn or -sc SOURCE_CONN
                          Source connection details
                          See: *Data Source Configurations* section for each data source
    --target-conn or -tc TARGET_CONN
                          Target connection details
                          See: *Connections* section for each data source
    --tables-list or -tbls SOURCE_SCHEMA.SOURCE_TABLE=TARGET_SCHEMA.TARGET_TABLE
                          Comma separated list of tables in the form schema.table=target_schema.target_table. Or shorthand schema.* for all tables.
                          Target schema name and table name are optional.
                          e.g.: 'bigquery-public-data.new_york_citibike.citibike_trips'
    [--bq-result-handler or -bqrh PROJECT_ID.DATASET.TABLE or CONNECTION_NAME.DATASET.TABLE]
                          BigQuery destination for validation results. Defaults to stdout.
                          See: *Validation Reports* section
    [--service-account or -sa PATH_TO_SA_KEY]
                          Service account to use for BigQuery result handler output.
    [--config-file or -c CONFIG_FILE]
                          YAML Config File Path to be used for storing validations and other features. Supports GCS and local paths.
                          See: *Running DVT with YAML Configuration Files* section
    [--config-file-json or -cj CONFIG_FILE_JSON]
                          JSON Config File Path to be used for storing validations only for application purposes.
    [--format or -fmt]    Format for stdout output. Supported formats are (text, csv, json, table).
                          Defaults  to table.
    [--filter-status or -fs STATUSES_LIST]
                          Comma separated list of statuses to filter the validation results. Supported statuses are (success, fail).
                          If no list is provided, all statuses are returned.
    [--exclusion-columns or -ec EXCLUSION_COLUMNS]
                          Comma separated list of columns to be excluded from the schema validation, e.g.: col_a,col_b.
    [--allow-list or -al ALLOW_LIST]
                          Comma separated list of data-type mappings of source and destination data sources which will be validated in case of missing data types in destination data source. e.g: "decimal(4,2):decimal(5,4),!string:string"
    [--allow-list-file ALLOW_LIST_FILE, -alf ALLOW_LIST_FILE]
                          YAML file containing default --allow-list mappings. Can be used in conjunction with --allow-list.
                          e.g.: samples/allow_list/oracle_to_bigquery.yaml or gs://dvt-allow-list-files/oracle_to_bigquery.yaml
                          See example files in samples/allow_list/.
  ```



  Below is the command syntax for custom query column validations.

  ```
  data-validation
    [--verbose or -v ]
                          Verbose logging
    [--log-level or -ll]
                          Log Level to be assigned. Supported levels are (DEBUG,INFO,WARNING,ERROR,CRITICAL). Defaults to INFO.
    validate custom-query column
    --source-conn or -sc SOURCE_CONN
                          Source connection details
                          See: *Data Source Configurations* section for each data source
    --target-conn or -tc TARGET_CONN
                          Target connection details
                          See: *Connections* section for each data source
    --source-query SOURCE_QUERY, -sq SOURCE_QUERY
                          Source sql query
                          Either --source-query or --source-query-file must be provided
    --source-query-file  SOURCE_QUERY_FILE, -sqf SOURCE_QUERY_FILE
                          File containing the source sql command. Supports GCS and local paths.
    --target-query TARGET_QUERY, -tq TARGET_QUERY
                          Target sql query
                          Either --target-query or --target-query-file must be provided
    --target-query-file TARGET_QUERY_FILE, -tqf TARGET_QUERY_FILE
                          File containing the target sql command. Supports GCS and local paths.
    [--count COLUMNS]     Comma separated list of columns for count or * for all columns
    [--sum COLUMNS]       Comma separated list of columns for sum or * for all numeric
    [--min COLUMNS]       Comma separated list of columns for min or * for all numeric
    [--max COLUMNS]       Comma separated list of columns for max or * for all numeric
    [--avg COLUMNS]       Comma separated list of columns for avg or * for all numeric
    [--std COLUMNS]       Comma separated list of columns for stddev_samp or * for all numeric
    [--exclude-columns or -ec]
                          Flag to indicate the list of columns provided should be excluded and not included.
    [--bq-result-handler or -bqrh PROJECT_ID.DATASET.TABLE or CONNECTION_NAME.DATASET.TABLE]
                          BigQuery destination for validation results. Defaults to stdout.
                          See: *Validation Reports* section
    [--service-account or -sa PATH_TO_SA_KEY]
                          Service account to use for BigQuery result handler output.
    [--config-file or -c CONFIG_FILE]
                          YAML Config File Path to be used for storing validations and other features. Supports GCS and local paths.
                          See: *Running DVT with YAML Configuration Files* section
    [--config-file-json or -cj CONFIG_FILE_JSON]
                          JSON Config File Path to be used for storing validations only for application purposes.
    [--labels or -l KEY1=VALUE1,KEY2=VALUE2]
                          Comma-separated key value pair labels for the run.
    [--format or -fmt FORMAT]
                          Format for stdout output. Supported formats are (text, csv, json, table). Defaults to table.
    [--filter-status or -fs STATUSES_LIST]
                          Comma separated list of statuses to filter the validation results. Supported statuses are (success, fail). If no list is provided, all statuses are returned.
  ```

  The default aggregation type is a 'COUNT *'. If no aggregation flag (i.e count,
  sum , min, etc.) is provided, the default aggregation will run.

  The [Examples](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/examples.md)
  page provides few examples of how this tool can be used to run custom query validations.




  (Note: Custom query row validation is not supported for FileSystem connections. Struct and array data types are not currently supported.)

  Below is the command syntax for row validations. In order to run row level
  validations you need to pass `--hash` flag which will specify the fields
  of the custom query result that will be concatenated and hashed. The primary key should be included
  in the SELECT statement of both source_query.sql and target_query.sql.  See *Primary Keys* section

  Below is the command syntax for custom query row validations.

  ```
  data-validation
    [--verbose or -v ]
                          Verbose logging
    [--log-level or -ll]
                          Log Level to be assigned. Supported levels are (DEBUG,INFO,WARNING,ERROR,CRITICAL). Defaults to INFO.
    validate custom-query row
    --source-conn or -sc SOURCE_CONN
                          Source connection details
                          See: *Data Source Configurations* section for each data source
    --target-conn or -tc TARGET_CONN
                          Target connection details
                          See: *Connections* section for each data source
    --source-query SOURCE_QUERY, -sq SOURCE_QUERY
                          Source sql query
                          Either --source-query or --source-query-file must be provided
    --source-query-file SOURCE_QUERY_FILE, -sqf SOURCE_QUERY_FILE
                          File containing the source sql command. Supports GCS and local paths.
    --target-query TARGET_QUERY, -tq TARGET_QUERY
                          Target sql query
                          Either --target-query or --target-query-file must be provided
    --target-query-file TARGET_QUERY_FILE, -tqf TARGET_QUERY_FILE
                          File containing the target sql command. Supports GCS and local paths.
    --comparison-fields or -comp-fields FIELDS
                          Comma separated list of columns to compare. Can either be a physical column or an alias
                          See: *Calculated Fields* section for details
    --hash '*'            '*' to hash all columns.
    --concat COLUMNS      Comma separated list of columns to concatenate or * for all columns
                          (use if a common hash function is not available between databases)
    [--primary-keys PRIMARY_KEYS, -pk PRIMARY_KEYS]
                         Common column between source and target queries for join
    [--exclude-columns or -ec]
                          Flag to indicate the list of columns provided should be excluded from hash or concat instead of included.
    [--bq-result-handler or -bqrh PROJECT_ID.DATASET.TABLE or CONNECTION_NAME.DATASET.TABLE]
                          BigQuery destination for validation results. Defaults to stdout.
                          See: *Validation Reports* section
    [--service-account or -sa PATH_TO_SA_KEY]
                          Service account to use for BigQuery result handler output.
    [--config-file or -c CONFIG_FILE]
                          YAML Config File Path to be used for storing validations and other features. Supports GCS and local paths.
                          See: *Running DVT with YAML Configuration Files* section
    [--config-file-json or -cj CONFIG_FILE_JSON]
                          JSON Config File Path to be used for storing validations only for application purposes.
    [--labels or -l KEY1=VALUE1,KEY2=VALUE2]
                          Comma-separated key value pair labels for the run.
    [--format or -fmt FORMAT]
                          Format for stdout output. Supported formats are (text, csv, json, table). Defaults to table.
    [--filter-status or -fs STATUSES_LIST]
                          Comma separated list of statuses to filter the validation results. Supported statuses are (success, fail). If no list is provided, all statuses are returned.
    [--trim-string-pks, -tsp]
                          Trims string based primary key values, intended for use when one engine uses padded string semantics (e.g. CHAR(n)) and the other does not (e.g. VARCHAR(n)).
    [--case-insensitive-match, -cim]
                          Performs a case insensitive match by adding an UPPER() before comparison.
  ```

  The [Examples](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/examples.md)
  page provides few examples of how this tool can be used to run custom query row validations.



  The `validate` command takes a `--dry-run` command line flag that prints source
  and target SQL to stdout as JSON in lieu of performing a validation:

  ```
  data-validation
    [--verbose or -v ]
                          Verbose logging
    [--log-level or -ll]
                          Log Level to be assigned. Supported levels are (DEBUG,INFO,WARNING,ERROR,CRITICAL). Defaults to INFO.
    validate
    [--dry-run or -dr]    Prints source and target SQL to stdout in lieu of performing a validation.
  ```

  For example, this flag can be used as follows:

  ```shell
  > data-validation validate --dry-run row \
    -sc my_bq_conn \
    -tc my_bq_conn \
    -tbls bigquery-public-data.new_york_citibike.citibike_stations \
    --primary-keys station_id \
    --hash '*'
  {
      "source_query": "SELECT `hash__all`, `station_id`\nFROM ...",
      "target_query": "SELECT `hash__all`, `station_id`\nFROM ..."
  }
  ```



  Running DVT with YAML configuration files is the recommended approach if:
  * you want to customize the configuration for any given validation OR
  * you want to run DVT at scale (i.e. run multiple validations sequentially or in parallel)

  We recommend generating YAML configs with the `--config-file <file-name>` flag when running a validation command, which supports
  GCS and local paths.

  You can use the `data-validation configs` command to run and view YAMLs.

  ```
  data-validation
    [--verbose or -v ]
                          Verbose logging
    [--log-level or -ll]
                          Log Level to be assigned. Supported levels are (DEBUG,INFO,WARNING,ERROR,CRITICAL). Defaults to INFO.
    configs run
    [--config-file or -c CONFIG_FILE]
                          Path to YAML config file to run. Supports local and GCS paths.
    [--config-dir or -cdir CONFIG_DIR]
                          Directory path containing YAML configs to be run sequentially. Supports local and GCS paths.
    [--dry-run or -dr]    If this flag is present, prints the source and target SQL generated in lieu of running the validation.
    [--kube-completions or -kc]
                          Flag to indicate usage in Kubernetes index completion mode.
                          See *Scaling DVT* section
  ```

  ```
  data-validation configs list
    [--config-dir or -cdir CONFIG_DIR]
                          GCS or local directory from which to list validation YAML configs. Defaults to current local directory.
  ```

  ```
  data-validation configs get
    [--config-file or -c CONFIG_FILE] GCS or local path of validation YAML to print.
  ```

  View the complete YAML file for a Grouped Column validation on the
  [Examples](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/examples.md#sample-yaml-config-grouped-column-validation) page.




  You can scale DVT for large validations by running the tool in a distributed manner. To optimize the validation speed for large tables, you can use GKE Jobs ([Google Kubernetes Jobs](https://cloud.google.com/kubernetes-engine/docs/how-to/deploying-workloads-overview#batch_jobs)) or [Cloud Run Jobs](https://cloud.google.com/run/docs/create-jobs). If you are not familiar with Kubernetes or Cloud Run Jobs, see [Scaling DVT with Distributed Jobs](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/internal/distributed_jobs.md) for a detailed overview.


  We recommend first generating partitions with the `generate-table-partitions` command for your large datasets (tables or queries). Then, use Cloud Run or GKE to distribute the validation of each chunk in parallel. See the [Cloud Run Jobs Quickstart sample](https://github.com/GoogleCloudPlatform/professional-services-data-validator/tree/develop/samples/cloud_run_jobs) to get started.

  When running DVT in a distributed fashion, both the `--kube-completions` and `--config-dir` flags are required. The `--kube-completions` flag specifies that the validation is being run in indexed completion mode in Kubernetes or as multiple independent tasks in Cloud Run. If the `-kc` option is used and you are not running in indexed mode, you will receive a warning and the container will process all the validations sequentially. If the `-kc` option is used and a config directory is not provided (i.e. a `--config-file` is provided instead), a warning is issued.

  The `--config-dir` flag will specify the directory with the YAML files to be executed in parallel. If you used `generate-table-partitions` to generate the YAMLs, this would be the directory where the partition files numbered `0000.yaml` to `<partition_num - 1>.yaml` are stored i.e (`gs://my_config_dir/source_schema.source_table/`). When creating your Cloud Run Job, set the number of tasks equal to the number of table partitions so the task index matches the YAML file to be validated. When executed, each Cloud Run task will validate a partition in parallel.




  The result handlers tell DVT where to store the results of
  each validation. The tool can write the results of a validation run to Google
  BigQuery or print to stdout (default). View the schema of the results
  table [here](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/terraform/results_schema.json).

  To output to BigQuery, simply include the `-bqrh` flag during a validation run
  like so:
  ```
  data-validation validate column
    -sc bq_conn
    -tc bq_conn
    -tbls bigquery-public-data.new_york_citibike.citibike_trips
    -bqrh project_id.dataset.table
    -sa service-acct@project.iam.gserviceaccount.com
  ```



  There are many occasions where you need to explore a data source while running
  validations. To avoid the need to open and install a new client, the CLI allows
  you to run ad hoc queries.

  ```
  data-validation query
    --conn or -c CONN
            The connection name to be queried
    --query or -q QUERY
            The raw query to run against the supplied connection
  ```



  Creating the list of matched tables can be a hassle. We have added a feature
  which may help you to match all of the tables together between source and
  target. The `find-tables` command:

  -   Pulls all tables in the source (applying a supplied `allowed-schemas` filter)
  -   Pulls all tables from the target
  -   Uses Jaro Similarity algorithm to match tables
  -   Finally, it prints a JSON list of tables which can be a reference for the
      validation run config.

  Note that our default value for the `score-cutoff` parameter is 1 and it seeks for identical matches. If no matches occur, reduce this value as deemed necessary. By using smaller numbers such as 0.7, 0.65 etc you can get more matches. For reference, we make use of [this jaro_similarity method](https://jamesturk.github.io/jellyfish/functions/#jaro-similarity) for the string comparison.

  ```
  data-validation find-tables --source-conn source --target-conn target \
      --allowed-schemas pso_data_validator \
      --score-cutoff 1
  ```



  There may be occasions we want to release a new CLI feature under a Beta flag.
  Any features under Beta may or may not make their way to production. However, if
  there is a Beta feature you wish to use than it can be accessed using the
  following.

  ```
  data-validation beta --help
  ```



  If you wish to use Data Validation as a Flask service, the following command
  will help. This same logic is also expected to be used for Cloud Run, Cloud
  Functions, and other deployment services.

  `data-validation beta deploy`




  Aggregate fields contain the SQL fields that you want to produce an aggregate
  for. Currently the functions `COUNT()`, `AVG()`, `SUM()`, `MIN()`, `MAX()`,
  and `STDDEV_SAMP()` are supported.

  Here is a sample aggregate config:
  ```yaml
  validations:
  - aggregates:
      - field_alias: count
      source_column: null
      target_column: null
      type: count
      - field_alias: count__tripduration
      source_column: tripduration
      target_column: tripduration
      type: count
      - field_alias: sum__tripduration
      source_column: tripduration
      target_column: tripduration
      type: sum
  ```

  If you are aggregating columns with large values, you can CAST() before aggregation
  with calculated fields as shown in [this example](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/examples.md#sample-yaml-with-calc-fields-cast-to-numeric-before-aggregation).



  Filters let you apply a WHERE statement to your validation query (ie. `SELECT *
  FROM table WHERE created_at > 30 days ago AND region_id = 71;`). The filter is
  written in the syntax of the given source and must reference columns in the
  underlying table, not projected DVT expressions.

  Note that you are writing the query to execute, which does not have to match
  between source and target as long as the results can be expected to align. If
  the target filter is omitted, the source filter will run on both the source and
  target tables.



  In many cases, validations (e.g. count, min, max etc) produce one row per table. The comparison between the source
  and target table is to compare the value for each column in the source with the value of the column in the target.
  `grouped-columns` validation and `validate row` produce multiple rows per table. Data Validation Tool needs one or more columns to uniquely identify each row so the source and target can be compared. Data Validation Tool refers to these columns as primary keys. These do not need to be primary keys in the table. The only requirement is that the keys uniquely identify the row in the results.

  These columns are inferred, where possible, from the source/target table or can be provided via the `--primary-keys` flag.



  Grouped Columns contain the fields you want your aggregations to be broken out
  by, e.g. `SELECT last_updated::DATE, COUNT(*) FROM my.table` will produce a
  resultset that breaks down the count of rows per calendar date.



  Row level validations can involve either a hash/checksum, concat, or comparison fields.
  A hash validation (`--hash '*'`) will first sanitize the data with the following
  operations on all or selected columns: CAST to string, IFNULL replace with a default
  replacement string and RSTRIP. Then, it will CONCAT() the results
  and run a SHA256() hash and compare the source and target results.

  When there are data type mismatches for columns, for example dates compared to timestamps and
  booleans compared with numeric columns, you may see other expressions in SQL statements which
  ensure that consistent values are used to build comparison values.

  Since each row will be returned in the result set if is recommended recommended to validate a
  subset of the table. The `--filters` and `--use-random-row` options can be used for this purpose.

  Please note that SHA256 is not a supported function on Teradata systems. If you wish to perform
  this comparison on Teradata you will need to [deploy a UDF to perform the conversion](https://github.com/akuroda/teradata-udf-sha2/blob/master/src/sha256.c).

  The concat validation (`--concat '*'`) will do everything up until the hash. It will sanitize
  and concatenate the specified columns, and then value compare the results.

  Comparison field validations (`--comp-fields column`) involve an value comparison of the
  column values. These values will be compared via a JOIN on their corresponding primary
  key and will be evaluated for an exact match.

  See hash and comparison field validations in the [Examples](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/examples.md#run-a-row-hash-validation-for-all-rows) page.



  Sometimes direct comparisons are not feasible between databases due to
  differences in how particular data types may be handled. These differences can
  be resolved by applying functions to columns in the query itself.
  Examples might include trimming whitespace from a string, converting strings to
  a single case to compare case insensitivity, or rounding numeric types to a
  significant figure.

  Once a calculated field is defined, it can be referenced by other calculated
  fields at any "depth" or higher. Depth controls how many subqueries are executed
  in the resulting query. For example, with the following YAML config:

  ```yaml
  - calculated_fields:
      - field_alias: rtrim_col_a
        source_calculated_columns: ['col_a']
        target_calculated_columns: ['col_a']
        type: rtrim
        depth: 0 # generated off of a native column
      - field_alias: ltrim_col_a
        source_calculated_columns: ['col_b']
        target_calculated_columns: ['col_b']
        type: ltrim
        depth: 0 # generated off of a native column
      - field_alias: concat_col_a_col_b
        source_calculated_columns: ['rtrim_col_a', 'ltrim_col_b']
        target_calculated_columns: ['rtrim_col_a', 'ltrim_col_b']
        type: concat
        depth: 1 # calculated one query above
  ```

  is equivalent to the following SQL query:

  ```sql
  SELECT
    CONCAT(rtrim_col_a, rtrim_col_b) AS concat_col_a_col_b
  FROM (
    SELECT
        RTRIM(col_a) AS rtrim_col_a
      , LTRIM(col_b) AS ltrim_col_b
    FROM my.table
    ) as table_0
  ```

  If you generate the config file for a row validation, you can see that it uses
  calculated fields to generate the query. You can also use calculated fields
  in column level validations to generate the length of a string, or cast
  a INT field to BIGINT for aggregations.

  See the [Examples page](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/examples.md#sample-yaml-with-calc-fields-cast-to-numeric-before-aggregation) for a sample
  cast to NUMERIC.



  DVT supports certain functions required for row hash validation natively (i.e. CAST() and CONCAT()),
  which are listed in the CalculatedField() class methods in the [QueryBuilder](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/data_validation/query_builder/query_builder.py).

  You can also specify custom functions (i.e. replace() or truncate()) from the Ibis expression
  [API reference](https://ibis-project.org/reference/expressions/generic/). Keep in mind these will run
  on both source and target systems. You will need to specify the Ibis API expression and the parameters
  required, if any, with the 'params' block as shown below:

  ```yaml
  - calculated_fields:
    - depth: 0
      field_alias: format_start_time
      source_calculated_columns:
      - start_time
      target_calculated_columns:
      - start_time
      type: custom
      ibis_expr: ibis.expr.types.TemporalValue.strftime
      params:
      - format_str: '%m%d%Y'
  ```

  The above block references the [TemporalValue.strftime](https://ibis-project.org/reference/expressions/timestamps/#ibis.expr.types.temporal.TemporalValue.strftime) Ibis API expression.
  See the [Examples page](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/docs/examples.md#sample-row-validation-yaml-with-custom-calc-field)
  for a sample YAML with a custom calculated field.



  Contributions are welcome. See the [Contributing guide](https://github.com/GoogleCloudPlatform/professional-services-data-validator/blob/develop/CONTRIBUTING.md) for details.


pkgId: 391f1849db0c8e4933ebbc3a9adbb5e612e9a0c71c9a09416a51b1877b1a2e18
name: python-google-vertex-haystack-help
arch: noarch
version: 4.0.1
epoch: 0
release: 1
summary: Development documents and examples for google-vertex-haystack
url: https://pypi.org/project/google-vertex-haystack/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-google-vertex-haystack-4.0.1-1.src.rpm
location_href: Packages/python-google-vertex-haystack-help-4.0.1-1.noarch.rpm
checksum_type: sha256
description:
  **Table of Contents**
  - [google-vertex-haystack](#google-vertex-haystack)
    - [Installation](#installation)
    - [Contributing](#contributing)
    - [License](#license)

  ```console
  pip install google-vertex-haystack
  ```

  `hatch` is the best way to interact with this project, to install it:
  ```sh
  pip install hatch
  ```
  With `hatch` installed, to run all the tests:
  ```
  hatch run test
  ```
  To run the linters `ruff` and `mypy`:
  ```
  hatch run lint:all
  ```

  `google-vertex-haystack` is distributed under the terms of the [Apache-2.0](https://spdx.org/licenses/Apache-2.0.html) license.


pkgId: d1bc3b908fb99911e238ada88cbd71b43af6ba38a9aa748f889b7a03832043c5
name: python-googleads-housekeeper-help
arch: noarch
version: 0.1.0
epoch: 0
release: 1
summary: Development documents and examples for googleads-housekeeper
url: https://pypi.org/project/googleads-housekeeper/
rpm_license: Apache 2.0
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-googleads-housekeeper-0.1.0-1.src.rpm
location_href: Packages/python-googleads-housekeeper-help-0.1.0-1.noarch.rpm
checksum_type: sha256
description:
  Managing Google Ads entities that can be excluded is a complex task which requires
  implementing many moving parts: parsing the rules, applying them, saving, updating,
  scheduling tasks and many more.



  Ads Housekeeper simplifies tasks related to managing excludable entities
  (placements, keywords, search terms, ads, etc) based on a set of custom rules.



  The library provides `googleads_housekeeper` module you can using in your projects
  which abstracts the following aspects:
  * Applying rules that identify entities for modification
  * Creating and managing tasks with aforementioned with built-in persistence mechanism
  * Sending notifications to a channel of your choice
  * Sending message to message broker of your choice





  1. Python 3.9+
  1. Google Ads API access and [google-ads.yaml](https://github.com/google/ads-api-report-fetcher/blob/main/docs/how-to-authenticate-ads-api.md#setting-up-using-google-adsyaml) file - follow documentation on [API authentication](https://github.com/google/ads-api-report-fetcher/blob/main/docs/how-to-authenticate-ads-api.md).



  ```
  pip install google-ads-housekeeper
  ```



  ```
  from googleads_housekeeper import bootstrap
  from googleads_housekeeper.domain import commands


  bus = bootstrap.bootstrap()


  task_id = 1
  cmd = commands.RunTask(task_id)
  bus.handle(cmd)
  ```



  This is not an officially supported Google product.


pkgId: 64a74637439e5d68e37cec8a05782eaae162844fd9dd78ef7be876c67e9a0b9e
name: python-gotenberg-client-help
arch: noarch
version: 0.8.2
epoch: 0
release: 1
summary: Development documents and examples for gotenberg-client
url: https://pypi.org/project/gotenberg-client/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gotenberg-client-0.8.2-1.src.rpm
location_href: Packages/python-gotenberg-client-help-0.8.2-1.noarch.rpm
checksum_type: sha256
description:
  - [Installation](#installation)
  - [What](#what)
  - [Why](#why)
    - [Features](#features)
  - [How](#how)
    - [Examples](#examples)
  - [License](#license)

  ```console
  pip install gotenberg-client
  ```

  This is a Python client for interfacing with [Gotenberg](https://gotenberg.dev/), which in turn is a wrapper around
  powerful tools for PDF generation and creation in various ways, using a stateless API. It's a very powerful tool
  to generate and manipulate PDFs.

  As far as I can tell, no active Python library exists to interface with the Gotenberg API.

  - HTTP/2 enabled by default
  - Abstract away the handling of multi-part/form-data and deal with `Path`s instead
  - Based on the modern [httpx](https://github.com/encode/httpx) library
  - Full support for type hinting and concrete return types as much as possible
  - Nearly full test coverage run against an actual Gotenberg server for multiple Python and PyPy versions

  All the routes and options from the Gotenberg routes are implemented, with the exception of the Prometheus metrics
  endpoint. All the routes use the same format and general idea.
  1. First, you add the file or files you want to process
  1. Then, configure the endpoint with its various options the route supports
  1. Finally, run the route and receive your resulting file
  - Files will be PDF or ZIP, depending on what endpoint and its configuration. Endpoints which handle
    multiple files, but don't merge them, return a ZIP archive of the resulting PDFs
  For more detailed examples, check the [documentation](https://stumpylog.github.io/gotenberg-client/latest/)

  Converting a single HTML file into a PDF:
  ```python
  from gotenberg_client import GotenbergClient
  with GotenbergClient("http://localhost:3000") as client:
      with client.chromium.html_to_pdf() as route:
        response = route.index("my-index.html").run()
        response.to_file(Path("my-index.pdf"))
  ```
  Converting an HTML file with additional resources into a PDF:
  ```python
  from gotenberg_client import GotenbergClient
  with GotenbergClient("http://localhost:3000") as client:
      with client.chromium.html_to_pdf() as route:
        response = route.index("my-index.html").resource("image.png").resource("style.css").run()
        response.to_file(Path("my-index.pdf"))
  ```
  Converting an HTML file with additional resources into a PDF/A1a format:
  ```python
  from gotenberg_client import GotenbergClient
  from gotenberg_client.options import PdfAFormat
  with GotenbergClient("http://localhost:3000") as client:
      with client.chromium.html_to_pdf() as route:
        response = route.index("my-index.html").resources(["image.png", "style.css"]).pdf_format(PdfAFormat.A2b).run()
        response.to_file(Path("my-index.pdf"))
  ```
  Converting a URL into PDF, in landscape format
  ```python
  from gotenberg_client import GotenbergClient
  from gotenberg_client.options import PageOrientation
  with GotenbergClient("http://localhost:3000") as client:
      with client.chromium.url_to_pdf() as route:
        response = route.url("https://hello.world").orient(PageOrientation.Landscape).run()
        response.to_file(Path("my-world.pdf"))
  ```
  Adding metadata to a PDF:
  This example shows how to add metadata to your generated PDF. All metadata fields are optional and include:
  - Document info (title, author, subject, keywords)
  - Dates (creation, modification)
  - Technical details (pdf version, creator, producer)
  - PDF standards (trapped status, marked status)
  ```python
  from gotenberg_client import GotenbergClient
  from datetime import datetime
  with GotenbergClient("http://localhost:3000") as client:
      with client.chromium.html_to_pdf() as route:
          response = (route
              .index("my-index.html")
              .metadata(
                  title="My Document",
                  author="John Doe",
                  subject="Example PDF",
                  keywords=["sample", "document", "test"],
                  creation_date=datetime.now(),
                  trapped="Unknown"
              )
              .run())
          response.to_file(Path("my-index.pdf"))
  ```
  To ensure the proper clean up of all used resources, both the client and the route(s) should be
  used as context manager. If for some reason you cannot, you should `.close` the client and any
  routes:
  ```python
  from gotenberg_client import GotenbergClient
  try:
    client = GotenbergClient("http://localhost:3000")
    try:
      route = client.merge(["myfile.pdf", "otherfile.pdf"]).run()
    finally:
      route.close()
  finally:
    client.close()
  ```
  The response from any `.run()` or `.run_with_retry()` will be either a `SingleFileResponse` or `ZipFileResponse`.
  There provide a slimmed down set of fields from an `httpx.Response`, including the headers, the status code and
  the response content. They also provide two convenience methods:
  - `to_file` - Accepts a path and writes the content of the response to it
  - `extract_to` - Only on a `ZipFileResponse`, extracts the zip into the given directory (which must exist)

  `gotenberg-client` is distributed under the terms of the [MPL 2.0](https://spdx.org/licenses/MPL-2.0.html) license.


pkgId: c9750ed0f74fd7d46ebfbe1d289a0d0c19dda596cafbf14454dfe1fc2b14c501
name: python-gotennet-pytorch-help
arch: noarch
version: 0.0.1
epoch: 0
release: 1
summary: Development documents and examples for gotennet-pytorch
url: https://pypi.org/project/gotennet-pytorch/
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gotennet-pytorch-0.0.1-1.src.rpm
location_href: Packages/python-gotennet-pytorch-help-0.0.1-1.noarch.rpm
checksum_type: sha256
description:
  <img src="./gotennet.png" width="450px"></img>



  Implementation of <a href="https://openreview.net/forum?id=5wxCQDtbMo">GotenNet</a>, new SOTA 3d equivariant transformer, in Pytorch

  I know a lot of researchers have moved on from geometric learning after Alphafold3. However, I just cannot help but <a href="https://arxiv.org/abs/2410.11443">wonder</a>. Hedging my bets



  ```bibtex
  @inproceedings{anonymous2024rethinking,
      title   = {Rethinking Efficient 3D Equivariant Graph Neural Networks},
      author  = {Anonymous},
      booktitle = {Submitted to The Thirteenth International Conference on Learning Representations},
      year    = {2024},
      url     = {https://openreview.net/forum?id=5wxCQDtbMo},
      note    = {under review}
  }
  ```

rpm_license:
  MIT License  Copyright (c) 2024 Phil Wang  Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:  The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


pkgId: a01b2285f382467f705afba5f8cd4c41cf66832b054a8afe71be4c94633ae514
name: python-gotennet-pytorch-help
arch: noarch
version: 0.0.17
epoch: 0
release: 1
summary: Development documents and examples for gotennet-pytorch
url: https://pypi.org/project/gotennet-pytorch/
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gotennet-pytorch-0.0.17-1.src.rpm
location_href: Packages/python-gotennet-pytorch-help-0.0.17-1.noarch.rpm
checksum_type: sha256
description:
  <img src="./gotennet.png" width="450px"></img>



  Implementation of <a href="https://openreview.net/forum?id=5wxCQDtbMo">GotenNet</a>, new SOTA 3d equivariant transformer, in Pytorch

  I know a lot of researchers have moved on from geometric learning after Alphafold3. However, I just cannot help but <a href="https://arxiv.org/abs/2410.11443">wonder</a>. Hedging my bets



  ```bash
  $ pip install gotennet-pytorch
  ```



  ```python
  import torch
  from gotennet_pytorch import GotenNet

  model = GotenNet(
      dim = 256,
      max_degree = 2,
      depth = 1,
      heads = 2,
      dim_head = 32,
      dim_edge_refinement = 256,
      return_coors = False
  )

  atom_ids = torch.randint(0, 14, (1, 12))
  coors = torch.randn(1, 12, 3)
  adj_mat = torch.randint(0, 2, (1, 12, 12)).bool()
  lens = torch.randint(1, 12, (1,))

  invariant, coors_out = model(atom_ids, adj_mat = adj_mat, coors = coors, lens = lens)
  ```



  ```bibtex
  @inproceedings{anonymous2024rethinking,
      title   = {Rethinking Efficient 3D Equivariant Graph Neural Networks},
      author  = {Anonymous},
      booktitle = {Submitted to The Thirteenth International Conference on Learning Representations},
      year    = {2024},
      url     = {https://openreview.net/forum?id=5wxCQDtbMo},
      note    = {under review}
  }
  ```

rpm_license:
[cell repeats an earlier one in this file: 1065 characters]


pkgId: 68cb32abaa4e0139ab7e0293f6c77efc408a33fc5a20f021c2e97024b9d7e0d9
name: python-gp2040ce-binary-tools-help
arch: noarch
version: 0.11.0
epoch: 0
release: 1
summary: Development documents and examples for gp2040ce-binary-tools
url: https://github.com/OpenStickCommunity/gp2040ce-binary-tools
rpm_license: GPL-3.0-or-later
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gp2040ce-binary-tools-0.11.0-1.src.rpm
location_href: Packages/python-gp2040ce-binary-tools-help-0.11.0-1.noarch.rpm
checksum_type: sha256
description:
  Tools for working with GP2040-CE binary dumps.



  While not necessary for most tools, you may want [picotool](https://github.com/raspberrypi/picotool) as an alternative
  way to dump binary data from the board. These dumps can be created with `gp2040ce-binary-tools` natively, but having an
  alternative way to create a binary dump can be helpful, as these tools work as well (or better) with a binary dump as
  over USB.



  All tools take `-P PATH` flag(s) in order to import Protobuf files (either precompiled Python files or raw .proto files)
  if you have them locally, in order to work with the latest (or development) version of the configuration. That said,
  this tool also includes a copy of the config files if you cannot supply these files, and will attempt to compile those
  as a fallback. Be aware, however, that they are a point in time snapshot, and may lag the real format in undesirable
  ways. Supply the latest Protobuf files if you can.

  An example of this invocation is:

  `visualize-config -P ~/proj/GP2040-CE/proto -P ~/proj/GP2040-CE/lib/nanopb/generator/proto --filename memory.bin`



  ```
  % pip install gp2040ce-binary-tools
  ```



  ```
  % git clone [URL to this repository]
  % cd gp2040ce-binary-tools
  % python -m venv venv
  % source ./venv/bin/activate
  % pip install -e .
  % pip install -Ur requirements/requirements-dev.txt
  ```



  In all cases, online help can be retrieved by providing the `-h` or ``--help`` flags to the below programs.



  [![asciicast](https://asciinema.org/a/67hELtUNkKCit4dFwYeAUa2fo.svg)](https://asciinema.org/a/67hELtUNkKCit4dFwYeAUa2fo)

  A terminal UI config editor, capable of viewing and editing existing configurations, can be launched via
  `edit-config`. It supports navigation both via the keyboard or the mouse, and can view and edit either a binary file
  made via `picotool` or configuration directly on the board in BOOTSEL mode over USB.

  Simple usage:

  | Key(s)                | Action                                                 |
  |-----------------------|--------------------------------------------------------|
  | Up, Down              | Move up and down the config tree                       |
  | Left, Right           | Scroll the tree left and right (when content is long)  |
  | Space                 | Expand a tree node to show its children                |
  | Enter                 | Expand a tree node, or edit a leaf node (bools toggle) |
  | Tab (in edit popup)   | Cycle highlight between input field and buttons        |
  | Enter (in edit popup) | Choose dropdown option or activate button              |
  | S                     | Save the config to the opened file                     |
  | Q                     | Quit without saving                                    |

  A quick demonstration of the editor is available [on asciinema.org](https://asciinema.org/a/67hELtUNkKCit4dFwYeAUa2fo).



  `concatenate` combines a GP2040-CE firmware .bin file (such as from a fresh build) with:

  * a GP2040-CE board config, in the form of
      * a config section .bin (with footer) (optionally padded) (`--binary-board-config-filename`) or
      * a JSON file representing the config (`--json-board-config-filename`)
  * and/or a GP2040-CE user config, in the form of
      * a config section .bin (with footer) (optionally padded) (`--binary-user-config-filename`) or
      * a JSON file representing the config (`--json-user-config-filename`)

  ...and produces a properly-offset firmware file suitable for flashing to a board with the provided config(s). This may
  be useful to ensure the board is flashed with a particular configuration, for instances such as producing a binary to
  flash many boards with a particular configuration (specific customizations, etc.), creating a file suitable for the
  initial install of a fresh board (a "board config"), or keeping documented backups of what you're testing with during
  development.

  The `--...-board-config-filename` flags allow for shipping a default configuration as part of the binary, replacing
  the need for generating these board configurations at compile time. This allows for more custom builds and less
  dependency on the build jobs, and is a feature in progress in the core firmware.

  The produced firmware + config(s) can be written to a file with `--new-filename FILENAME` or straight to a RP2040
  in BOOTSEL mode with `--usb`. The output file is a direct binary representation by default, but if `FILENAME` ends in
  ".uf2", it will be written in the UF2 format, which is generally more convenient to the end user.

  Sample usage:

  ```
  % concatenate build/GP2040-CE_foo_bar.bin --binary-user-config-filename storage-dump.bin \
      --new-filename new-firmware-with-config.bin
  ```



  `dump-config` replaces the need for picotool in order to make a copy of the GP2040-CE configuration as a binary file.
  This could be used with the other tools, or just to keep a backup.

  Sample usage:

  ```
  % dump-config `date +%Y%m%d`-config-backup.bin
  ```



  `dump-gp2040ce` replaces the need for picotool in order to make a copy of a board's full GP2040-CE image as a binary file.
  This could be used with the other tools, or just to keep a backup.

  Sample usage:

  ```
  % dump-gp2040ce `date +%Y%m%d`-backup.bin
  ```



  `summarize-gp2040ce` prints information regarding the provided USB device or file. It attempts to detect the firmware
  and/or board config and/or user config version, which might be useful for confirming files are built properly, or to
  determine the lineage of something.

  Sample usage:

  ```
  % summarize-gp2040ce --usb
  USB device:

  GP2040-CE Information
    detected GP2040-CE version:     v0.7.8-9-g59e2d19b-dirty
    detected board config version:  v0.7.8-board-test
    detected user config version:   v0.7.8-RC2-1-g882235b3
  ```



  `visualize-config` reads a GP2040-CE board's configuration, either over USB or from a dump of the board's flash
  storage section, and prints it out for visual inspection or diffing with other tools. It can also find the storage
  section from a GP2040-CE whole board dump, if you have that instead. Usage is simple; just connect your board in BOOTSEL
  mode or pass the tool your binary file to analyze along with the path to the Protobuf files.

  Sample output:

  ```
  % visualize-config --usb
  boardVersion: "v0.7.2"
  gamepadOptions {
    inputMode: INPUT_MODE_HID
    dpadMode: DPAD_MODE_DIGITAL
    socdMode: SOCD_MODE_SECOND_INPUT_PRIORITY
    invertXAxis: false
    invertYAxis: false
    switchTpShareForDs4: true
    lockHotkeys: false
  }
  hotkeyOptions {
    hotkeyF1Up {
      dpadMask: 1
      action: HOTKEY_SOCD_UP_PRIORITY
    }
    hotkeyF1Down {
      dpadMask: 2
      action: HOTKEY_SOCD_NEUTRAL
    }
    ...[and so on]...
  }
  pinMappings {
    pinDpadUp: 19
    pinDpadDown: 18
    pinDpadLeft: 16
    pinDpadRight: 17
    pinButtonB1: 8
    pinButtonB2: 7
    pinButtonB3: 12
    pinButtonB4: 11
    pinButtonL1: 9
    pinButtonR1: 10
    pinButtonL2: 5
    pinButtonR2: 6
    pinButtonS1: 15
    pinButtonS2: 13
    pinButtonL3: 21
    pinButtonR3: 22
    pinButtonA1: 14
    pinButtonA2: 20
  }
  ...[and so on]...
  addonOptions {
    bootselButtonOptions {
      enabled: false
      buttonMap: 0
    }
    ...[and so on]...
    dualDirectionalOptions {
      enabled: true
      upPin: 23
      downPin: 27
      leftPin: 26
      rightPin: 24
      dpadMode: DPAD_MODE_DIGITAL
      combineMode: 3
    }
    ...[and so on]...
  }
  forcedSetupOptions {
    mode: FORCED_SETUP_MODE_OFF
  }
  ```





  The GP2040-CE configuration is still changing, so the tools are changing accordingly. This project doesn't currently make
  a huge effort to be backwards compatible, so instead, refer to this:



  * `gp2040ce-binary-tools >=v0.6.0` supports both board and user configs still being developed in `GP2040-CE`.
  * `gp2040ce-binary-tools >=v0.5.1` supported the increased user config size in `GP2040-CE >=v0.7.5`.
  * `gp2040ce-binary-tools <=v0.5.0` supported the smaller user config size in `GP2040-CE <v0.7.5`.



  The latest update of the configuration snapshot is from **v0.7.8**.



  Some of these tools require a dump of your GP2040-CE board, either the storage section or the whole board, depending on
  the context. The storage section of a GP2040-CE board is a reserved 16 KB starting at `0x101FC000`. To dump your board's
  storage with picotool:

  ```
  % picotool save -r 101FC000 10200000 memory.bin
  ```

  And to dump your whole board:

  ```
  % picotool save -a whole-board.bin
  ```



  Written by and copyright Brian S. Stephan (<bss@incorporeal.org>).

  gp2040ce-binary-tools is free software: you can redistribute it and/or modify it under the terms of the GNU General
  Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any
  later version.

  gp2040ce-binary-tools is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the
  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
  details.

  You should have received a copy of the GNU General Public License along with gp2040ce-binary-tools. If not, see
  <https://www.gnu.org/licenses/>.


pkgId: 4642cc77085611979e4efda317e3f7a600638bc78d6317f146220689a4b0eb94
name: python-gpbacay-arcane-help
arch: noarch
version: 0.2.1
epoch: 0
release: 1
summary: Development documents and examples for gpbacay-arcane
url: https://github.com/gpbacay/gpbacay_arcane
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gpbacay-arcane-0.2.1-1.src.rpm
location_href: Packages/python-gpbacay-arcane-help-0.2.1-1.noarch.rpm
checksum_type: sha256
description:
  **gpbacay_arcane** is a Python library designed for custom neuromimetic artificial neural network mechanisms, built on top of TensorFlow and Keras. It is specifically developed for the **A.R.C.A.N.E** (Augmented Reconstruction of Consciousness through Artificial Neural Evolution) project, enabling the creation of adaptive, biologically-inspired neural networks.



  - **Custom Layers and Mechanisms**: Includes dynamic reservoirs, spiking neurons, Hebbian learning, self-modeling, and more.
  - **Neuromimetic Capabilities**: Built for advanced spatio-temporal processing and homeostatic plasticity.
  - **TensorFlow and Keras Integration**: Seamlessly integrates with TensorFlow and Keras to build sophisticated neural networks.



  To install the library, simply run:

  ```bash
  pip install gpbacay-arcane


pkgId: a8ded87a4ccb3bd500cf97f08c466171fa7622f250a25720088e89dd644270ba
name: python-gpddatabase-help
arch: noarch
version: 0.0.0
epoch: 0
release: 1
summary: Development documents and examples for gpddatabase
url: https://github.com/opengpd/gpddatabase
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gpddatabase-0.0.0-1.src.rpm
location_href: Packages/python-gpddatabase-help-0.0.0-1.noarch.rpm
checksum_type: sha256
description:
  **About:** The project aims to provide a database for studying GPDs. It is a collaborative effort by scientists working in this field.

  **Mission:** The mission is to provide open access to GPD datasets for researchers around the world, facilitating easier integration of existing and new data into phenomenological analyses. By improving reproducibility, the project aims to help the research community fully adopt open-science standards. In addition, the database can serve as an aggregation point to store benchmarks for theoretical developments. This open, accessible resource is designed to accelerate research in the field of GPDs.

  **Key Features:** The proposed database is a streamlined, efficient resource for storing both experimental and lattice-QCD data relevant to GPD research. Using a lightweight format based on YAML serialization, the database easily captures essential analysis details, including replica values for advanced statistical work. It supports seamless integration with analysis codes through Python and C++ interfaces, making it a practical tool for researchers working on various aspects of GPD phenomenology.

  **License:** This project is strictly for the non-profit scientific use, and is distributed under GPL-3.0 license.

  **Resources:**
    * Webpage: [https://opengpd.github.io/gpddatabase](https://opengpd.github.io/gpddatabase)
    * PyPi repository: [https://pypi.org/project/gpddatabase](https://pypi.org/project/gpddatabase)
    * Reference article: []()


pkgId: 7a5f272a502a2f3285cc7ccd263e6b42b31d681b921e23324b4caa9787c10614
name: python-gpiod-sysfs-proxy-help
arch: noarch
version: 0.1.2
epoch: 0
release: 1
summary: Development documents and examples for gpiod-sysfs-proxy
url: https://github.com/brgl/gpiod-sysfs-proxy
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gpiod-sysfs-proxy-0.1.2-1.src.rpm
location_href: Packages/python-gpiod-sysfs-proxy-help-0.1.2-1.noarch.rpm
checksum_type: sha256
description:
  <!-- SPDX-License-Identifier: MIT -->
  <!-- SPDX-FileCopyrightText: 2024 Bartosz Golaszewski <bartosz.golaszewski@linaro.org> -->



  [libgpiod](https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/)-based
  compatibility layer for the linux GPIO sysfs interface.

  It uses [FUSE](https://www.kernel.org/doc/html/v6.3/filesystems/fuse.html)
  (Filesystem in User Space) in order to expose a filesystem that can be mounted
  over `/sys/class/gpio` to simulate the kernel interface.



  Running the script with a mountpoint parameter will mount the simulated gpio
  class directory and then exit. The script can also be run with `-f` or `-d`
  switches for foreground or debug operation respectively.

  The recommended command-line mount options to use are:

  ```
  gpiod-sysfs-proxy <mountpoint> -o nonempty -o allow_other -o default_permissions -o entry_timeout=0
  ```

  This allows to mount the compatibility layer on non-empty `/sys/class/gpio`,
  allows non-root users to access it, enables permission checks by the kernel
  and disables caching of entry stats (for when we remove directories from the
  script while the kernel doesn't know it).

  For a complete list of available command-line options, please run:

  ```
  gpiod-sysfs-proxy --help
  ```



  Due to how FUSE works, there are certain limitations to the level of
  compatibility we can assure as well as some other issues the user may need
  to have to work around.



  If the GPIO sysfs interface is disabled in Kconfig, the `/sys/class/gpio`
  directory will not exist and the user-space can't create directories inside
  of sysfs. There are two solutions: either the user can use a different
  mountpount or - for full backward compatibility - they can use overlayfs on
  top of `/sys/class` providing the missing `gpio` directory.

  Example:

  ```
  mkdir -p /run/gpio/sys /run/gpio/class/gpio /run/gpio/work
  mount -t sysfs sysfs /run/gpio/sys
  mount -t overlay overlay -o lowerdir=/run/gpio/sys/class,upperdir=/run/gpio/class,workdir=/run/gpio/work,ro
  gpiod-sysfs-proxy /sys/class/gpio <options>
  ```



  The kernel sysfs interface at `/sys/class/gpio` contains links to directories
  living elsewhere (specifically: under the relevant device entries) in sysfs.
  For obvious reasons we cannot replicate that so, instead we expose actual
  directories representing GPIO chips and exported GPIO lines.



  We currently don't support multiple users polling the `value` attribute at
  once. Also: unlike the kernel interface, reading from `value` will not block
  after the value has been read once.



  Some legacy GPIO drivers hard-code the base GPIO number. We don't yet support
  it but it's planned as a future extension in the form of an argument that will
  allow to associate a hard-coded base with a GPIO chip by its label.


pkgId: 273ddd306e93aadd8f0ca9ae80a08e5b695d48741ebe7f132cd94addce04f490
name: python-gplugins-help
arch: noarch
version: 1.2.1
epoch: 0
release: 1
summary: Development documents and examples for gplugins
url: https://pypi.org/project/gplugins/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gplugins-1.2.1-1.src.rpm
location_href: Packages/python-gplugins-help-1.2.1-1.noarch.rpm
checksum_type: sha256
description:
  [![docs](https://github.com/gdsfactory/gplugins/actions/workflows/pages.yml/badge.svg)](https://gdsfactory.github.io/gplugins/)
  [![PyPI](https://img.shields.io/pypi/v/gplugins)](https://pypi.org/project/gplugins/)
  [![PyPI Python](https://img.shields.io/pypi/pyversions/gplugins.svg)](https://pypi.python.org/pypi/gplugins)
  [![MIT](https://img.shields.io/github/license/gdsfactory/gplugins)](https://choosealicense.com/licenses/mit/)
  [![codecov](https://img.shields.io/codecov/c/github/gdsfactory/gplugins)](https://codecov.io/gh/gdsfactory/gdsfactory/tree/main/gplugins)

  GDSFactory plugins:

  - `devsim` TCAD device simulator.
  - `meow` Eigen Mode Expansion (EME).
  - `femwell` Finite Element Method Solver (heaters, modes, TCAD, RF waveguides).
  - `gmsh` mesh structures.
  - `tidy3d` Finite Difference Time Domain (FDTD) simulations on the cloud using GPU.
  - `lumerical` For Ansys FDTD and Circuit interconnect.
  - `klayout` for fill, dataprep and testing.
  - `ray` for distributed computing and optimization.
  - `schematic`: for bokeh schematic editor and `path_length_analysis`.
  - `meep` for FDTD.
  - `mpb` for MPB mode solver.
  - `elmer` for electrostatic (capacitive) simulations.
  - `palace` for full-wave driven (S parameter) and electrostatic (capacitive) simulations.
  - `sax` S-parameter circuit solver.
  - `vlsir` for parsing GDS-extracted circuit netlists into Cadence Spectre, NgSpice and Xyce Schematic File formats.
  - `luminescent` for FDTD simulations.




  You can install most plugins with:

  ```bash
  pip install "gdsfactory[full]" --upgrade
  ```

  or

  ```bash
  pip install "gplugins[devsim,femwell,gmsh,schematic,meow,meshwell,ray,sax,tidy3d]" --upgrade
  ```

  Or install only the plugins you need. For example:

  ```bash
  pip install "gplugins[schematic,femwell,meow,sax,tidy3d]" --upgrade

  ```



  The following plugins require special installation as they can't be installed with `pip`:

  - For Meep and MPB you need to use `conda` or `mamba` on MacOS, Linux or [Windows WSL (Windows Subsystem for Linux)](https://learn.microsoft.com/en-us/windows/wsl/install) with `conda install pymeep=*=mpi_mpich_* -c conda-forge -y`
  - For Elmer, refer to [Elmer FEM – Installation](https://www.elmerfem.org/blog/binaries/) for installation or compilation instructions each platform. Gplugins assumes `ElmerSolver`, `ElmerSolver_mpi`, and `ElmerGrid` are available in your PATH environment variable.
  - For Palace, refer to [Palace – Installation](https://awslabs.github.io/palace/stable/install/) for compilation instructions using Spack or Singularity. Gplugins assumes `palace` is available in your PATH environment variable.



  We recommend `uv` for installing GDSFactory:

  ```bash

  curl -LsSf https://astral.sh/uv/install.sh | sh
  ```

  ```bash

  powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
  ```

  Then you can install gdsfactory with:

  ```bash
  uv venv --python 3.11
  uv sync --extra docs --extra dev
  ```




  - [Read docs](https://gdsfactory.github.io/gplugins/)
  - [Read gdsfactory docs](https://gdsfactory.github.io/gdsfactory/)
  - [![Join the chat at https://gitter.im/gdsfactory-dev/community](https://badges.gitter.im/gdsfactory-dev/community.svg)](https://gitter.im/gdsfactory-dev/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)


pkgId: 8a7b9a09ed38e815bf6404d67061bf9dd8eecb243672e0a21e67d596ebc901ed
name: python-gppc-help
arch: noarch
version: 0.1.10
epoch: 0
release: 1
summary: Development documents and examples for gppc
url: https://pypi.org/project/gppc/
rpm_license: GNU AGPLv3
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gppc-0.1.10-1.src.rpm
location_href: Packages/python-gppc-help-0.1.10-1.noarch.rpm
checksum_type: sha256
description:
  Check OSRS Grand Exchange prices from the command line. Includes module functionality to check full price history of an item.
  Features caching capability to save item price histories for future use.





  ```bash
  $ pip install gppc
  ```

  ```bash
  $ git clone https://github.com/moxxos/gppc.git
  $ cd gppc
  $ pip install .
  ```



  ```bash
  $ gppc 'gold bar' coal
  $ gppc gold_bar coal
  ```
  ![Image](https://raw.githubusercontent.com/moxxos/gppc/main/gppc_example.jpg)



  ```python
  >>> import gppc
  >>> gppc.search('coal')
  ```





  ```python
  >>> from gppc import Item
  >>> coal = Item('coal')
  ```

  ```
  >>> coal.history_1day
                timestamp  avgHighPrice  avgLowPrice  highPriceVolume  lowPriceVolume
  0   2023-09-20 04:15:00         276.0          264            18195           31276
  1   2023-09-20 04:20:00         289.0          265             7124           82582
  2   2023-09-20 04:25:00         278.0          262            18889           80672
  ..                  ...           ...          ...              ...             ...
  362 2023-09-21 11:20:00         256.0          244            26604           89559
  363 2023-09-21 11:25:00         256.0          243            42930          194245
  364 2023-09-21 11:30:00         256.0          244            22929           66926

  [365 rows x 5 columns]
  ```

  ```
  >>> coal.history_1year
                timestamp  avgHighPrice  avgLowPrice  highPriceVolume  lowPriceVolume
  0   2022-09-20 20:00:00           144          142          7290293         8857481
  1   2022-09-21 20:00:00           144          143          5821183         8728784
  2   2022-09-22 20:00:00           147          145          5148730         9724897
  ..                  ...           ...          ...              ...             ...
  362 2023-09-17 20:00:00           221          217          8200818        14460078
  363 2023-09-18 20:00:00           243          236          8815340        20995587
  364 2023-09-19 20:00:00           236          235          8746294        17259336

  [365 rows x 5 columns]
  ```

  ```
  >>> hist_2week = coal.history_2week
  >>> hist_3month = coal.history_3month
  ```

  ```
  >>> coal_hist_1d = coal.history_1day
  >>> coal_hist_2w = coal.history_2week
  >>> coal_hist_3m = coal.history_3month
  >>> coal_hist_1y = coal.history_1year
  >>> coal.save_history()
  1281 new records added for item: Coal

  >>> bond_hist_1y = bond.history_1year
  >>> bond.save_history()
  365 new records added for item: Old school bond
  ```

  ```
  >>> coal.full_history
                 timestamp  avgHighPrice  avgLowPrice  highPriceVolume  lowPriceVolume
  0    2022-09-20 20:00:00         144.0          142          7290293         8857481
  1    2022-09-21 20:00:00         144.0          143          5821183         8728784
  2    2022-09-22 20:00:00         147.0          145          5148730         9724897
  ...                  ...           ...          ...              ...             ...
  1278 2023-09-21 18:20:00         253.0          245             2090           47719
  1279 2023-09-21 18:25:00         252.0          245            11647           70886
  1280 2023-09-21 18:30:00         246.0          244            20901           49703

  [1281 rows x 5 columns]
  ```

  ```python
  >>> from gppc import Catalog
  >>> ores = Catalog('copper ore', 'tin ore', 'iron ore', 'gold ore', 'silver ore', 'mithril ore', 'adamantite ore', 'runite ore')
  >>> ores.sort()
  >>> ores
  ['Adamantite ore', 'Copper ore', 'Gold ore', 'Iron ore', 'Mithril ore', 'Runite ore', 'Silver ore', 'Tin ore']
  >>> ores.remove('Gold ore')
  >>> ores
  ['Adamantite ore', 'Copper ore', 'Iron ore', 'Mithril ore', 'Runite ore', 'Silver ore', 'Tin ore']
  ```

  ```
  >>> ores.save_history('1day')
  365 new records added for item: Adamantite ore
  365 new records added for item: Copper ore
  365 new records added for item: Iron ore
  365 new records added for item: Mithril ore
  365 new records added for item: Runite ore
  365 new records added for item: Silver ore
  365 new records added for item: Tin ore
  ```

  ```python
  >>> all_items = Catalog()
  >>> len(all_items)
  4005
  ```






  - [ ] Finish command line display
  - [ ] Add tests and documentation


pkgId: 2435eb68f7228a65feda3c28f043ddfba6f28cffc56a0b89ba1b22975bb5bfd4
name: python-gpsea-help
arch: noarch
version: 0.9.0
epoch: 0
release: 1
summary: Development documents and examples for gpsea
url: https://pypi.org/project/gpsea/
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gpsea-0.9.0-1.src.rpm
location_href: Packages/python-gpsea-help-0.9.0-1.noarch.rpm
checksum_type: sha256
description:
  [![Build status](https://github.com/monarch-initiative/gpsea/workflows/CI/badge.svg)](https://github.com/monarch-initiative/gpsea/actions/workflows/python_ci.yml)
  [![GitHub release](https://img.shields.io/github/release/monarch-initiative/gpsea.svg)](https://github.com/monarch-initiative/gpsea/releases)
  ![PyPi downloads](https://img.shields.io/pypi/dm/gpsea.svg?label=Pypi%20downloads)
  ![PyPI - Python Version](https://img.shields.io/pypi/pyversions/gpsea)

  GPSEA (Genotypes and Phenotypes - Statistical Evaluation of Associations) is a Python package for finding genotype-phenotype associations.


  See the [Tutorial](https://monarch-initiative.github.io/gpsea/stable/tutorial.html)
  and a comprehensive [User guide](https://monarch-initiative.github.io/gpsea/stable/user-guide/index.html)
  for more information.

  The documentation comes in two flavors:

  - [Stable documentation](https://monarch-initiative.github.io/gpsea/stable/) (last release on `main` branch)
  - [Latest documentation](https://monarch-initiative.github.io/gpsea/latest) (bleeding edge, latest commit on `develop` branch)

rpm_license:
  MIT License  Copyright (c) 2023, The Monarch Initiative  Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:  The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


pkgId: 59745116de8b44b7a48eb98410b41c1a3dbfee0fb736451ae72a42ae454031a6
name: python-gpt-multi-atomic-agents-help
arch: noarch
version: 0.6.4
epoch: 0
release: 1
summary: Development documents and examples for gpt-multi-atomic-agents
url: https://github.com/mrseanryan/gpt-multi-atomic-agents
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gpt-multi-atomic-agents-0.6.4-1.src.rpm
location_href: Packages/python-gpt-multi-atomic-agents-help-0.6.4-1.noarch.rpm
checksum_type: sha256
description:
  A simple dynamic multi-agent framework based on [atomic-agents](https://github.com/BrainBlend-AI/atomic-agents) and [Instructor](https://github.com/instructor-ai/instructor). Uses the power of [Pydantic](https://docs.pydantic.dev) for data and schema validation and serialization.

  - compose Agents made of a system prompt, with a shared language of either **Function Calls** or else **GraphQL mutations**
  - convert user input into data modifications (functions or GraphQL mutations)
  - to maximise user engagement, uses a 2-phase process:
    - Planning Phase:
      - a router uses an LLM to process complex 'composite' user prompts, and automatically route them to the best sequence of your agents
        - the router rewrites the user prompt, to best suit each agent
        - an execution plan is generated
        - the client can use the `router` to iterate over the execution plan, with user feedback
    - Generation Phase:
        - when the user is happy -> the client can use the `generator` to execute the plan, using the recommended agents
        - the client then receives function calls (or GraphQL mutations) to update the data
  - generate via OpenAI or AWS Bedrock or groq
  - usage:
    1. as a library
    2. OR run out-of-the-box as a REST API, accepting Agents from the client
      - there is a simple [TypeScript framework](https://github.com/mrseanryan/gpt-multi-atomic-agents/tree/master/clients/gpt-maa-ts), for writing Agent-based TypeScript clients of the REST API
    3. OR as a command line chat-loop

  > **_NOTE:_** The `!! framework is at an early stage !!` - breaking changes will be indicated by increasing the *minor* version (major is still at zero).

  [url_repo]: https://github.com/mrseanryan/gpt-multi-atomic-agents
  [url_semver_org]: https://semver.org/

  [![MIT License][img_license]][url_license]
  [![Supported Python Versions][img_pyversions]][url_pyversions]
  [![gpt-multi-atomic-agents][img_version]][url_version]

  [![PyPI Releases][img_pypi]][url_pypi]
  [![PyPI - Downloads](https://img.shields.io/pypi/dm/gpt-multi-atomic-agents.svg)](https://pypi.org/project/gpt-multi-atomic-agents)

  [img_license]: https://img.shields.io/badge/License-MIT-blue.svg
  [url_license]: https://github.com/mrseanryan/gpt-multi-atomic-agents/blob/master/LICENSE

  [url_version]: https://pypi.org/project/gpt-multi-atomic-agents/

  [img_version]: https://img.shields.io/static/v1.svg?label=SemVer&message=gpt-multi-atomic-agents&color=blue
  [url_version]: https://pypi.org/project/bumpver/

  [img_pypi]: https://img.shields.io/badge/PyPI-wheels-green.svg
  [url_pypi]: https://pypi.org/project/gpt-multi-atomic-agents/#files

  [img_pyversions]: https://img.shields.io/pypi/pyversions/gpt-multi-atomic-agents.svg
  [url_pyversions]: https://pypi.python.org/pypi/gpt-multi-atomic-agents

  [![ko-fi](https://ko-fi.com/img/githubbutton_sm.svg)](https://ko-fi.com/K3K73ALBJ)



  An LLM based Agents Framework using an Agent Oriented Programming approach to orchestrate agents using a shared language.

  The agent language can either be **Function Calling** based, or else **GraphQL** based.

  The framework is generic and allows agents to be defined in terms of a name, description, accepted input calls, and allowed output calls.

  The agents communicate indirectly using a blackboard. The language is composed of (Function or GraphQL mutation) calls: each agent specifies what it understands as input, and what calls it is able to generate. Each agent can be configured to understand a subset of the output of the other agents. In this way, the agents can understand each other's output and collaborate together.

  ![System overview](https://raw.githubusercontent.com/mrseanryan/gpt-multi-atomic-agents/master/images/diagram-Multi-LLM-based-Agent-collaboration-via-Dynamic-Router-GraphQL-context.jpg)

  A router takes the user prompt and generates an agent execution plan.

  The execution plan uses the best sequence of the most suitable agents, to handle the user prompt.

  The router rewrites the user prompt to suit each agent, which improves quality and avoids unwanted output.

  > **_NOTE:_** Optionally, the router can be run separately, allowing for human-in-the-loop feedback on the execution plan that the router generated. In this way, the user can collaborate more with the router, before the generative agents are actually executed.

  > **_NOTE:_** An agent is serializable (basically a JSON document), so Agents can be imported, exported and even edited by clients as needed.

  - this allows the user to have more control over the output, and has the added benefit of reducing the *perceived* time taken to generate, since the user has intermediate interaction with the router.

  Finally, the output is returned in the form of an ordered list of (Function or GraphQL) calls.

  To read more about this approach, you can see this [Medium article](https://medium.com/@mr.sean.ryan/multi-llm-based-agent-collaboration-via-dynamic-router-and-graphql-handle-composite-prompts-with-83e16a22a1cb).

  > **_NOTE:_** The `framework is at an early stage`. The Evaluator is not currently implemented.



  When integrating, depending on which kind of Agent Definitions are used, the client needs to:

  - **Function Calling Agents:** client implements the functions. The client executes the functions according to the results (function calls) generated by this framework.
    - this approach is less flexible but good for simple use cases where GraphQL may be too complicated
  - **GraphQL based Agents:** The client executes the GraphQL mutations on the GraphQL document they earlier submitted to the framework.
    - this approach provides the most flexibility:
      - the input is a GraphQL schema with any previouly made mutation calls, the output is a set of mutation calls
      - the agents can communicate generations (modifications to data) by generating GraphQL mutations that match the given schema





  This is a demo 'Sim Life' world builder.
  It uses 3 agents (Creature Creature, Vegetation Creator, Relationship Creator) to process user prompts.
  The agents are defined in terms of functions.
  The output is a series of Function Calls which can be implemented by the client, to build the Sim Life world.



  The AddCreature function:

  ```python
  function_add_creature = FunctionSpecSchema(
      function_name="AddCreature",
      description="Adds a new creature to the world (not vegetation)",
      parameters=[
          ParameterSpec(name="creature_name", type=ParameterType.string),
          ParameterSpec(name="allowed_terrain", type=ParameterType.string, allowed_values=terrain_types),
          ParameterSpec(name="age", type=ParameterType.int),
          ParameterSpec(name="icon_name", type=ParameterType.string, allowed_values=creature_icons),
      ]
  )
  ```

  The AddCreatureRelationship function:

  ```python
  function_add_relationship = FunctionSpecSchema(
      function_name="AddCreatureRelationship",
      description="Adds a new relationship between two creatures",
      parameters=[
          ParameterSpec(
              name="from_name", type=ParameterType.string
          ),
          ParameterSpec(
              name="to_name", type=ParameterType.string
          ),
          ParameterSpec(
              name="relationship_name",
              type=ParameterType.string,
              allowed_values=["eats", "buys", "feeds", "sells"],
          ),
      ],
  )
  ```



  The Creature Creator agent is defined declaratively in terms of:

  - its description (a very short prompt)
  - its input schema (a list of accepted function definitions)
  - its output schema (a list of output function definitions)

  Agents can collaborate and exchange information indirectly, by reusing the same function defintions via a blackboard.

  ```python
  def build_creature_agent():
      agent_definition = build_function_agent_definition(
          agent_name="Creature Creator",
          description="Creates new creatures given the user prompt. Ensures that ALL creatures mentioned by the user are created.",
          accepted_functions=[function_add_creature, function_add_relationship],
          functions_allowed_to_generate=[function_add_creature],
          topics=["creature", "summary"]
      )

      return agent_definition
  ```

  Notes about the Creature Creator agent:
  - this agent can only generate "AddCreature" function calls.
  - the agent also accepts (understands) previous "AddCreature" calls, so that it knows what has already been created.
  - additionally, this agent understands a subset of function calls from agents: here, it understands the "AddRelationship" function defined by `function_add_relationship`. This allows the agents to collaborate. See the [example source code](https://github.com/mrseanryan/gpt-multi-atomic-agents/tree/master/examples/sim_life) for more details.





  This is a demo 'Sim Life' world builder.
  It uses 3 agents (Creature Creature, Vegetation Creator, Relationship Creator) to process user prompts.
  The agents are defined declaratively in terms of GraphQL input schema, and allowed generated mutations.
  The output is a series of GraphQL mutations which can be executed by the client, to build the Sim Life world.



  The GraphQL schema:

  ```graphql
  type Creature {
    id: ID!
    creature_name: String!
    allowed_terrain: TerrainType!
    age: Int!
    icon_name: IconType!
  }

  type Vegetation {
    id: ID!
    vegetation_name: String!
    icon_name: IconType!
    allowed_terrain: TerrainType!
  }

  type Relationship {
    id: ID!
    from_name: String!
    to_name: String!
    relationship_kind: RelationshipType!
  }
  ...
  ```

  The GraphQL mutations that we want the Agents to generate, are distinct for each agent:

  Creature Creator agent:

  ```graphql
  type Mutation {
    addCreature(input: CreatureInput!): Creature!
  }

  input CreatureInput {
    creature_name: String!
    allowed_terrain: TerrainType!
    age: Int!
    icon_name: IconType!
  }
  ```

  Vegetation Creator agent:

  ```graphql
  type Mutation {
    addVegetation(input: VegetationInput!): Vegetation!
  }

  input VegetationInput {
    vegetation_name: String!
    icon_name: IconType!
    allowed_terrain: TerrainType!
  }
  ```



  The Creature Creator agent is defined declaratively in terms of:

  - its description (a very short prompt)
  - its input schema (a list of accepted GraphQL schemas)
  - its output schema (a list of output GraphQL mutation calls)

  An agent is basically a composition of input and output schemas, together with a prompt.

  Agents collaborate and exchange information indirectly via a blackboard, by reusing the same GraphQL schemas and mutation calls.

  ```python
  creatures_graphql = _read_schema("creature.graphql")
  creature_mutations_graphql = _read_schema("creature.mutations.graphql")

  def build_creature_agent():
      agent_definition = build_graphql_agent_definition(
          agent_name="Creature Creator",
          description="Creates new creatures given the user prompt. Ensures that ALL creatures mentioned by the user are created.",
          accepted_graphql_schemas=[creatures_graphql, creature_mutations_graphql],
          mutations_allowed_to_generate=[creature_mutations_graphql],
          topics=["creature", "summary"]
      )

      return agent_definition
  ```

  Notes about this agent:
  - this agent can only generate mutations that are defined by `creature_mutations_graphql` from the file "creature.mutations.graphql".
  - the agent also accepts (understands) previous mutations calls, so that it knows what has already been created (`creature_mutations_graphql`).
  - additionally, this agent understands the shared GraphQL schema defined by `creatures_graphql` from the file "creature.graphql".
    - This array of GraphQL files can also be used to allow an Agent to understand a subset of the mutations output by other agents. This allows the agents to collaborate.
    - See the [example source code](https://github.com/mrseanryan/gpt-multi-atomic-agents/tree/master/examples/sim_life_via_graphql) for more details.



  The agents can be used together to form a chat bot:

  ```python
  from gpt_multi_atomic_agents import functions_expert_service, config
  from . import agents

  def run_chat_loop(given_user_prompt: str|None = None) -> list:
      CHAT_AGENT_DESCRIPTION = "Handles users questions about an ecosystem game like Sim Life"

      agent_definitions = [
          build_creature_agent(), build_relationship_agent(), build_vegatation_agent()  # for more capabilities, add more agents here
      ]

      _config = config.Config(
          ai_platform = config.AI_PLATFORM_Enum.bedrock_anthropic,
          model = config.ANTHROPIC_MODEL,
          max_tokens = config.ANTHROPIC_MAX_TOKENS,
          is_debug = False
          )

      return functions_expert_service.run_chat_loop(agent_definitions=agent_definitions, chat_agent_description=CHAT_AGENT_DESCRIPTION, _config=_config, given_user_prompt=given_user_prompt)
  ```

  > note: if `given_user_prompt` is not set, then `run_chat_loop()` will wait for user input from the keyboard

  See the [example source code](https://github.com/mrseanryan/gpt-multi-atomic-agents/tree/master/examples) for more details.



  USER INPUT:
  ```
  Add a sheep that eats grass
  ```

  OUTPUT:
  ```
  Generated 3 function calls
  [Agent: Creature Creator] AddCreature( creature_name=sheep, icon_name=sheep-icon, land_type=prairie, age=1 )
  [Agent: Plant Creator] AddPlant( plant_name=grass, icon_name=grass-icon, land_type=prairie )
  [Agent: Relationship Creator] AddCreatureRelationship( from_name=sheep, to_name=grass, relationship_name=eats )
  ```

  Because the framework has a dynamic router, it can handle more complex 'composite' prompts, such as:

  > Add a cow that eats grass. Add a human - the cow feeds the human. Add and alien that eats the human. The human also eats cows.

  The router figures out which agents to use, what order to run them in, and what prompt to send to each agent.

  Optionally, the router can be re-executed with user feedback on its genereated plan, before actually executing the agents.

  The recommended agents are then executed in order, building up their results in the shared blackboard.

  Finally, the framework combines the resulting calls together and returns them to the client.



  ![example run - function calls](https://raw.githubusercontent.com/mrseanryan/gpt-multi-atomic-agents/master/images/screenshot-example-run.png)




  USER INPUT:
  ```
  Add a sheep that eats grass
  ```

  OUTPUT:
  ```
  ['mutation {\n    addCreature(input: {\n      creature_name: "sheep",\n      allowed_terrain: GRASSLAND,\n      age: 2,\n      icon_name: SHEEP\n    }) {\n      creature_name\n      allowed_terrain\n      age\n      icon_name\n    }\n  }']
  ['mutation {', '  addVegetation(input: {', '    vegetation_name: "Grass",', '    icon_name: GRASS,', '    allowed_terrain: LAND', '  }) {', '    vegetation_name', '    icon_name', '    allowed_terrain', '  }', '}']
  ['mutation {', '  addCreatureRelationship(input: {', '    from_name: "Sheep",', '    to_name: "Grass",', '    relationship_kind: EATS', '  }) {', '    id', '  }', '}']
  ```



  ![example run - GraphQL](https://raw.githubusercontent.com/mrseanryan/gpt-multi-atomic-agents/master/images/screenshot-example-run.graphql.png)



  0. Install Python 3.11 and [poetry](https://github.com/python-poetry/install.python-poetry.org)

  1. Install dependencies.

  ```
  poetry install
  ```

  2. Setup your credentials for your preferred AI platform.

  For OpenAI:

  - You need to get an Open AI key.
  - Set environment variable for your  with your Open AI key:

  ```
  export OPENAI_API_KEY="xxx"
  ```

  Add that to your shell initializing script (`~/.zprofile` or similar)

  Load in current terminal:

  ```
  source ~/.zprofile
  ```



  gpt-multi-atomic-agents can be used in three ways:

  1 - as a framework for your application or service
  2 - as a REST API, where a client provides the agents and user prompts
  3 - as a command line tool to chat and generate functions to modify your data



  See the [example source code](https://github.com/mrseanryan/gpt-multi-atomic-agents/tree/master/examples) for more details.



  ```
  ./run-rest-api.sh
  ```

  The REST API URL and Swagger URLs are printed to the console

  The available REST methods:

  - generate_plan: Optionally call this before generate_function_calls, in order to generate an Execution Plan separately, and get user feedback. This can help reduce *perceived* latency for the user.

  - generate_function_calls: Generates Function Calls to fulfill the user's prompt, given the available Agents in the user's request. If an Execution Plan is included in the request, then that is used to decide which Agents to execute. Otherwise an Execution Plan will be internally generated.

  - [Not yet implemented] generate_graphql



  There is a simple TypeScript framework, for writing Agent-based TypeScript clients of the REST API.

  For an example with simple Agents, see the [TypeScript Framework README](https://github.com/mrseanryan/gpt-multi-atomic-agents/tree/master/clients/gpt-maa-ts) and the [TypeScript Example Agents](https://github.com/mrseanryan/gpt-multi-atomic-agents/tree/master/clients/gpt-maa-ts/src/test_gpt_maa_client.ts).



  Chat to generate mutations (Function Calls or GraphQL) with the configured Agents. The Blackboard can be saved out for later chatting, or it can be consumed by other tools, for example to execute against application data.

  The example command line chats are setup with the same Sim Life style example agents.

  Via function calling:

  ```
  ./run-example.sh
  ```

  Via GraphQL:


  ```
  ./run-example.graphql.sh
  ```

  ```
  🤖 Assistant : Welcome to multi-agent chat
  Type in a question for the AI. If you are not sure what to type, then ask it a question like 'What can you do?'
  To exit, use the quit command
  Available commands:
    clear - Clear the blackboard, starting over. (alias: reset)
    dump - Dump the current blackboard state to the console (alias: show)
    help - Display help text
    list - List the local data files from previous blackboards
    load - Load a blackboard from the local data store
    save - Save the blackboard to the local data store
    quit - Exit the chat loop (alias: bye, exit, stop)
  ```



  ```
  ./test.sh
  ```


pkgId: ba808e55548c3c1b7d504f83074b46612d70ee93b5143cb9ea83608d67a0a543
name: python-gpt-researcher-help
arch: noarch
version: 0.10.4
epoch: 0
release: 1
summary: Development documents and examples for gpt-researcher
url: https://github.com/assafelovic/gpt-researcher
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gpt-researcher-0.10.4-1.src.rpm
location_href: Packages/python-gpt-researcher-help-0.10.4-1.noarch.rpm
checksum_type: sha256
description:
  <p align="center">
  <a href="https://star-history.com/#assafelovic/gpt-researcher">
    <picture>
      <source media="(prefers-color-scheme: dark)" srcset="https://api.star-history.com/svg?repos=assafelovic/gpt-researcher&type=Date&theme=dark" />
      <source media="(prefers-color-scheme: light)" srcset="https://api.star-history.com/svg?repos=assafelovic/gpt-researcher&type=Date" />
      <img alt="Star History Chart" src="https://api.star-history.com/svg?repos=assafelovic/gpt-researcher&type=Date" />
    </picture>
  </a>
  </p>
  <p align="right">
    <a href="#top">⬆️ Back to Top</a>
  </p>


pkgId: bdb74011c7f78cc897b8cde4ea56ee23cdde7a13a8464f4444fffff87c7de055
name: python-gptbioinsightor-help
arch: noarch
version: 0.6.0
epoch: 0
release: 1
summary: Development documents and examples for gptbioinsightor
url: https://github.com/huang-sh/GPTBioInsightor
rpm_license: BSD 3-Clause
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gptbioinsightor-0.6.0-1.src.rpm
location_href: Packages/python-gptbioinsightor-help-0.6.0-1.noarch.rpm
checksum_type: sha256
description:
  <table>
      <tr>
          <td><img src="https://raw.githubusercontent.com/huang-sh/GPTBioInsightor/main/docs/en/source/img/logo.png"></td><td>GPTBioInsightor is a tool designed for single-cell data analysis, particularly beneficial for newcomers to a biological field or those in interdisciplinary areas who may lack sufficient biological background knowledge. GPTBioInsightor utilizes the powerful capabilities of large language models to help people quickly gain knowledge and insight, enhancing their work efficiency.</td>
      </tr>
  </table>



  Please checkout the documentations at:
  - English: [GPTBioInsightor docs](https://gptbioinsightor.readthedocs.io/en/latest/)
  - 中文: [GPTBioInsightor 文档](https://gptbioinsightor.readthedocs.io/zh-cn/latest/)


   - openai
   - anthropic
   - openrouter
   - groq
   - aliyun
   - zhipuai
   - siliconflow
   - deepseek
   - perplexity




  Install GPTBioInsightor from PyPi:
  ```shell
  pip install gptbioinsightor
  ```




  ```python
  import gptbioinsightor as gbi


  import os

  os.environ['API_KEY'] = "sk-***"

  os.environ['ANTHROPIC_API_KEY'] = "sk-***"



  background = "Human Healthy Donor PBMCs"



  res = gbi.get_celltype(adata, background=background,
                         out="gbi.claude.celltype.md",
                         topnumber=15,provider="anthropic",
                         n_jobs=4,model="claude-3-5-sonnet-20241022")








  ```

  It will output a markdown file, like:
  ```markdown




  \```
  LDHB, LTB, RGCC, IL32, NOSIP, CD3D, CD3E, TMEM123, VIM, TMEM66, FYB, JUNB, CCR7, CD27, MYL12A
  \```



  **Key Markers**:
  - Cell-specific: CD3D, CD3E, CCR7, CD27, FYB
  - Context-specific: LTB, JUNB, VIM

  **Evidence and Reasoning**
  - **PRIMARY EVIDENCE**: The presence of CD3D and CD3E, which are essential components of the T cell receptor complex, strongly indicates a T cell population. These markers are highly specific to T cells.
  - **SECONDARY EVIDENCE**: CCR7 is a chemokine receptor that is typically expressed on naïve and central memory T cells, suggesting that these cells may be in a non-activated or memory state.
  - **ADDITIONAL EVIDENCE**: CD27 and FYB are also known to be expressed in T cells, particularly in activated T cells. LTB (lymphotoxin beta) and JUNB (a transcription factor) are involved in T cell activation and function.

  **Validation**: Other gold standard markers for T cells (not in Geneset 0) include CD4, CD8, and TCRα/β. For CD4+ T cells, additional markers like CD45RA and CD45RO can be used to distinguish between naïve and memory T cells.


  - **Alternative celltype1: NK cells**
      - **WHY Alternative? Key MARKERS, Evidence and Reasoning**: NK cells can express some of the markers found in this geneset, such as CCR7 and CD27, but the presence of CD3D and CD3E, which are not expressed in NK cells, makes this less likely.
      - **OTHER Gold Standard MARKERS(NOT IN Geneset 0) TO VALIDATE THE Alternative celltype1**: NK cells would typically express NKp46, KIRs, and NKG2D, which are not present in this geneset.

  - **Alternative celltype2: B cells**
      - **WHY Alternative? Key MARKERS, Evidence and Reasoning**: B cells do not typically express CD3D and CD3E, which are strong T cell markers. However, some B cell markers like CD27 and CCR7 are present, which might lead to confusion. The absence of B cell-specific markers like CD19 and CD20 makes this alternative less likely.
      - **OTHER Gold Standard MARKERS(NOT IN Geneset 0) TO VALIDATE THE Alternative celltype2**: B cells would typically express CD19, CD20, and surface IgM, which are not present in this geneset.


  - **NOTEWORTHY PATTERNS**: The co-expression of CCR7 and CD27 suggests a population of T cells that are either naïve or central memory T cells.
  - **CELL STATE**: The expression of JUNB and LTB, along with other activation-related genes, suggests that these T cells may be in an activated or recently activated state.
  - **POTENTIAL NEW FINDINGS**: The presence of VIM (vimentin), a marker often associated with mesenchymal cells, in T cells is intriguing and could indicate a unique subset of T cells or a state of T cells that have undergone some form of stress or activation leading to the upregulation of vimentin.

  ```



  - Shenghui Huang (hsh-me@outlook.com)


pkgId: 40f0f67c17a29b6d007deec15981af68de2d97ab3db58f79691189166d25aef8
name: python-gptify-help
arch: noarch
version: 0.5.0
epoch: 0
release: 1
summary: Development documents and examples for gptify
url: https://github.com/ogre-run/gptify
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gptify-0.5.0-1.src.rpm
location_href: Packages/python-gptify-help-0.5.0-1.noarch.rpm
checksum_type: sha256
description:
  `gptify` is a command-line tool that transforms a Git repository into a single text file or multiple text chunks suitable for use with Large Language Models (LLMs) like ChatGPT. It preserves the file structure and content, enabling LLMs to understand and process the codebase for tasks such as code review, documentation generation, and answering questions about the code. This project is a fork of [gptrepo](https://github.com/zackess/gptrepo) with added features.



  This tool addresses the challenge of effectively using LLMs with codebases. By converting a repository into a digestible format, `gptify` allows developers to leverage the power of LLMs for various development tasks.  It simplifies the process of feeding code context into LLMs, avoiding size limitations and formatting issues.



  The easiest way to install `gptify` is using `pip`:

  ```bash
  pip install gptify
  ```

  Alternatively, you can install it using `pipx`:

  ```bash
  poetry build && pipx install dist/*.whl
  ```

  You can also uninstall older versions using the provided install script:

  ```bash
  ./install.sh
  ```



  1. **Navigate to the root directory** of your Git repository.
  2. **Run the `gptify` command**:

  ```bash
  gptify
  ```

  This will generate a file named `gptify_output.txt` in the current directory containing the formatted repository content.  You can then copy and paste the contents of this file into a ChatGPT session.




  * `--output <filename>`: Specifies the name of the output file (default: `gptify_output.txt`).
  * `--clipboard`: Copies the output directly to the clipboard instead of creating an output file.
  * `--openfile`: Opens the output file after creation using the default system application.
  * `--preamble <filepath>`: Prepends a custom preamble to the output file.  This is useful for providing instructions or context to the LLM.
  * `--chunk`: Enables chunking of the output into smaller files, useful for handling large repositories that exceed LLM context limits. Used with `--max_tokens` and `--overlap`.
  * `--max_tokens`:  Sets the maximum number of tokens per chunk when using the `--chunk` option (default: 900000).  Requires the `tiktoken` library.
  * `--overlap`: Sets the number of overlapping tokens between chunks when using the `--chunk` option (default: 400). Helps maintain context across chunks. Requires the `tiktoken` library.
  * `--output_dir`: Specifies the output directory for chunks when using `--chunk` (default: `gptify_output_chunks`).




  ```bash
  gptify --output my_repo.txt --preamble instructions.txt
  ```

  This command will generate `my_repo.txt` with the processed repository data, prepended with the content of `instructions.txt`.



  ```bash
  gptify --chunk --max_tokens 4000 --overlap 200
  ```
  This will create multiple files in the `gptify_output_chunks` directory, each containing a chunk of the repository data, with a maximum of 4000 tokens and an overlap of 200 tokens.



  Contributions are welcome.



  This project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details.


pkgId: b73b35da7fb14ad1cd06d4f13e0f8297d978cd10b1d36ef110cd7287108c5f2f
name: python-gptme-rag-help
arch: noarch
version: 0.5.1
epoch: 0
release: 1
summary: Development documents and examples for gptme-rag
url: https://github.com/ErikBjare/gptme-rag
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gptme-rag-0.5.1-1.src.rpm
location_href: Packages/python-gptme-rag-help-0.5.1-1.noarch.rpm
checksum_type: sha256
description:
  A powerful RAG (Retrieval-Augmented Generation) system that enhances AI interactions by providing relevant context from your local files. Built primarily for [gptme](https://github.com/ErikBjare/gptme), but can be used standalone.

  RAG systems improve AI responses by retrieving and incorporating relevant information from a knowledge base into the generation process. This leads to more accurate, contextual, and factual responses.

  <p align="center">
    <a href="https://github.com/ErikBjare/gptme-rag/actions/workflows/test.yml">
      <img src="https://github.com/ErikBjare/gptme-rag/actions/workflows/test.yml/badge.svg" alt="Tests" />
    </a>
    <a href="https://pypi.org/project/gptme-rag/">
      <img src="https://img.shields.io/pypi/v/gptme-rag" alt="PyPI version" />
    </a>
    <a href="https://github.com/ErikBjare/gptme-rag/blob/master/LICENSE">
      <img src="https://img.shields.io/github/license/ErikBjare/gptme-rag" alt="License" />
    </a>
    <br>
    <a href="https://github.com/ErikBjare/gptme">
      <img src="https://img.shields.io/badge/built%20using-gptme%20%F0%9F%A4%96-5151f5?style=flat" alt="Built using gptme" />
    </a>
  </p>



  - 📚 Document indexing with ChromaDB
    - Fast and efficient vector storage
    - Semantic search capabilities
    - Persistent storage
  - 🔍 Semantic search with embeddings
    - Relevance scoring
    - Token-aware context assembly
    - Clean output formatting
  - 📄 Smart document processing
    - Streaming large file handling
    - Automatic document chunking
    - Configurable chunk size/overlap
    - Document reconstruction
  - 👀 File watching and auto-indexing
    - Real-time index updates
    - Pattern-based file filtering
    - Efficient batch processing
    - Automatic persistence
  - 🛠️ CLI interface for testing and development
    - Index management
    - Search functionality
    - Context assembly
    - File watching



  ```bash

  pipx install gptme-rag  # or: pip install gptme-rag


  gptme-rag index ./docs --pattern "**/*.md"


  gptme-rag search "What is the architecture of the system?"
  ```

  For development installation:
  ```bash
  git clone https://github.com/ErikBjare/gptme-rag.git
  cd gptme-rag
  poetry install
  ```





  ```bash

  gptme-rag index /path/to/documents --pattern "**/*.md"


  gptme-rag index /path/to/documents --persist-dir ./index
  ```



  ```bash

  gptme-rag search "your query here"


  gptme-rag search "your query" \
    --n-results 5 \
    --persist-dir ./index \
    --max-tokens 4000 \
    --show-context
  ```



  The watch command monitors directories for changes and automatically updates the index:

  ```bash

  gptme-rag watch /path/to/documents


  gptme-rag watch /path/to/documents \
    --pattern "**/*.{md,py}" \
    --ignore-patterns "*.tmp" "*.log" \
    --persist-dir ./index
  ```

  Features:
  - 🔄 Real-time index updates
  - 🎯 Pattern matching for file types
  - 🚫 Configurable ignore patterns
  - 🔋 Efficient batch processing
  - 💾 Automatic persistence

  The watcher will:
  - Perform initial indexing of existing files
  - Monitor for file changes (create/modify/delete/move)
  - Update the index automatically
  - Handle rapid changes efficiently with debouncing
  - Continue running until interrupted (Ctrl+C)



  The benchmark commands help measure and optimize performance:

  ```bash

  gptme-rag benchmark indexing /path/to/documents \
    --pattern "**/*.md" \
    --persist-dir ./benchmark_index


  gptme-rag benchmark search /path/to/documents \
    --queries "python" "documentation" "example" \
    --n-results 10


  gptme-rag benchmark watch-perf /path/to/documents \
    --duration 10 \
    --updates-per-second 5
  ```

  Features:
  - 📊 Comprehensive metrics
    - Operation duration
    - Memory usage
    - Throughput
    - Custom metrics per operation
  - 🔬 Multiple benchmark types
    - Document indexing
    - Search operations
    - File watching
  - 📈 Performance tracking
    - Memory efficiency
    - Processing speed
    - System resource usage

  Example benchmark output:
  ```plaintext
  ┏━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━┓
  ┃ Operation      ┃ Duration(s) ┃ Memory(MB) ┃ Throughput ┃ Additional Metrics ┃
  ┡━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━┩
  │ indexing       │      0.523 │     15.42 │   19.12/s │ files: 10         │
  │ search         │      0.128 │      5.67 │   23.44/s │ queries: 3        │
  │ file_watching  │      5.012 │      8.91 │    4.99/s │ updates: 25       │
  └────────────────┴────────────┴───────────┴───────────┴──────────────────┘
  ```



  The indexer supports automatic document chunking for efficient processing of large files:

  ```bash

  gptme-rag index /path/to/documents \
    --chunk-size 1000 \
    --chunk-overlap 200


  gptme-rag search "your query" \
    --group-chunks \
    --n-results 5
  ```

  Features:
  - 🔄 Streaming processing
    - Handles large files efficiently
    - Minimal memory usage
    - Progress reporting
  - 📑 Smart chunking
    - Configurable chunk size
    - Overlapping chunks for context
    - Token-aware splitting
  - 🔍 Enhanced search
    - Chunk-aware relevance
    - Result grouping by document
    - Full document reconstruction

  Example Output:
  ```plaintext
  Most Relevant Documents:

  1. documentation.md#chunk2 (relevance: 0.85)
    Detailed section about configuration options, including chunk size and overlap settings.
    [Part of: documentation.md]

  2. guide.md#chunk5 (relevance: 0.78)
    Example usage showing how to process large documents efficiently.
    [Part of: guide.md]

  3. README.md#chunk1 (relevance: 0.72)
    Overview of the chunking system and its benefits for large document processing.
    [Part of: README.md]

  Full Context:
  Total tokens: 850
  Documents included: 3 (from 3 source documents)
  Truncated: False
  ```

  The chunking system automatically:
  - Splits large documents into manageable pieces
  - Maintains context across chunk boundaries
  - Groups related chunks in search results
  - Provides document reconstruction when needed





  ```bash

  poetry run pytest


  poetry run pytest --cov=gptme_rag
  ```



  ```plaintext
  gptme_rag/
  ├── __init__.py
  ├── cli.py               # CLI interface
  ├── indexing/           # Document indexing
  │   ├── document.py    # Document model
  │   └── indexer.py     # ChromaDB integration
  ├── query/             # Search functionality
  │   └── context_assembler.py  # Context assembly
  └── utils/             # Utility functions
  ```



  1. Fork the repository
  2. Create a feature branch
  3. Make your changes
  4. Add tests for new functionality
  5. Run tests and linting
  6. Submit a pull request



  Releases are automated through GitHub Actions. The process is:
  1. Update version in pyproject.toml
  2. Commit the change: `git commit -am "chore: bump version to x.y.z"`
  3. Create and push a tag: `git tag vx.y.z && git push origin master vx.y.z`
  4. Create a GitHub release (can be done with `gh release create vx.y.z`)
  5. The publish workflow will automatically:
     - Run tests
     - Build the package
     - Publish to PyPI



  This package is designed to integrate with [gptme](https://github.com/ErikBjare/gptme) to provide AI assistants with relevant context from your local files. When used with gptme, it:

  - Automatically indexes your project files
  - Enhances AI responses with relevant context
  - Provides semantic search across your codebase
  - Maintains a persistent knowledge base
  - Assembles context intelligently within token limits

  To use with gptme, simply install both packages and gptme will automatically detect and use gptme-rag for context management.



  MIT License. See [LICENSE](LICENSE) for details.


pkgId: 147746f79cc22a1db5a5b9a60fd95ec0183e6c2de290f93a267c9e2c6d8c1306
name: python-gptree-cli-help
arch: noarch
version: 1.0.0
epoch: 0
release: 1
summary: Development documents and examples for gptree-cli
url: https://pypi.org/project/gptree-cli/
rpm_license: MIT
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gptree-cli-1.0.0-1.src.rpm
location_href: Packages/python-gptree-cli-help-1.0.0-1.noarch.rpm
checksum_type: sha256
description:
  When working with Large Language Models (LLMs) to continue or debug your coding projects, providing the right context is key. `gptree` simplifies this by:
  1. Generating a clear **directory tree structure** of your project.
  2. Combining the **contents of relevant files** into a single output text file.
  3. Allowing you to **select files interactively** to fine-tune which files are included.


pkgId: 898fe5b2b59a6825094330d3dbfda0c201e89da55cd0cc34a0a8f66968d59b66
name: python-gpustack-help
arch: noarch
version: 0.4.1
epoch: 0
release: 1
summary: Development documents and examples for gpustack
url: https://pypi.org/project/gpustack/
rpm_license: None
rpm_group: Unspecified
rpm_buildhost: localhost
rpm_sourcerpm: python-gpustack-0.4.1-1.src.rpm
location_href: Packages/python-gpustack-help-0.4.1-1.noarch.rpm
checksum_type: sha256
description:
  <br>
  <p align="center">
      <img alt="GPUStack" src="./docs/assets/gpustack-logo.png" width="300px"/>
  </p>
  <br>
  <p align="center">
      <a href="https://docs.gpustack.ai" target="_blank">
          <img alt="Documentation" src="https://img.shields.io/badge/Docs-GPUStack-blue?logo=readthedocs&logoColor=white"></a>
      <a href="./LICENSE" target="_blank">
          <img alt="License" src="https://img.shields.io/github/license/gpustack/gpustack?logo=github&logoColor=white&label=License&color=blue"></a>
      <a href="./docs/assets/wechat-assistant.png" target="_blank">
          <img alt="WeChat" src="https://img.shields.io/badge/Wechat-GPUStack-blue?logo=wechat&logoColor=white"></a>
      <a href="https://discord.gg/VXYJzuaqwD" target="_blank">
          <img alt="Discord" src="https://img.shields.io/badge/Discord-GPUStack-blue?logo=discord&logoColor=white"></a>
      <a href="https://twitter.com/intent/follow?screen_name=gpustack_ai" target="_blank">
          <img alt="Follow on X(Twitter)" src="https://img.shields.io/twitter/follow/gpustack_ai?logo=X"></a>
  </p>
  <br>

  ![demo](docs/assets/gpustack-demo.gif)

  GPUStack is an open-source GPU cluster manager for running AI models.



  - **Broad Hardware Compatibility:** Run with different brands of GPUs in Apple MacBooks, Windows PCs, and Linux servers.
  - **Broad Model Support:** From LLMs and diffusion models to audio, embedding, and reranker models.
  - **Scales with Your GPU Inventory:** Easily add more GPUs or nodes to scale up your operations.
  - **Distributed Inference**: Supports both single-node multi-GPU and multi-node inference and serving.
  - **Multiple Inference Backends**: Supports llama-box (llama.cpp) and vLLM as the inference backends.
  - **Lightweight Python Package:** Minimal dependencies and operational overhead.
  - **OpenAI-compatible APIs:** Serve APIs that are compatible with OpenAI standards.
  - **User and API key management:** Simplified management of users and API keys.
  - **GPU metrics monitoring:** Monitor GPU performance and utilization in real-time.
  - **Token usage and rate metrics:** Track token usage and manage rate limits effectively.





  GPUStack provides a script to install it as a service on systemd or launchd based systems. To install GPUStack using this method, just run:

  ```bash
  curl -sfL https://get.gpustack.ai | sh -s -
  ```



  Run PowerShell as administrator (**avoid** using PowerShell ISE), then run the following command to install GPUStack:

  ```powershell
  Invoke-Expression (Invoke-WebRequest -Uri "https://get.gpustack.ai" -UseBasicParsing).Content
  ```



  For manual installation, docker installation or detailed configuration options, please refer to the [Installation Documentation](https://docs.gpustack.ai/latest/installation/installation-script/).



  1. Run and chat with the **llama3.2** model:

  ```bash
  gpustack chat llama3.2 "tell me a joke."
  ```

  2. Run and generate an image with the **stable-diffusion-v3-5-large-turbo** model:

  > ### 💡 Tip
  >
  > This command downloads the model (~12GB) from Hugging Face. The download time depends on your network speed. Ensure you have enough disk space and VRAM (12GB) to run the model. If you encounter issues, you can skip this step and move to the next one.

  ```bash
  gpustack draw hf.co/gpustack/stable-diffusion-v3-5-large-turbo-GGUF:stable-diffusion-v3-5-large-turbo-Q4_0.gguf \
  "A minion holding a sign that says 'GPUStack'. The background is filled with futuristic elements like neon lights, circuit boards, and holographic displays. The minion is wearing a tech-themed outfit, possibly with LED lights or digital patterns. The sign itself has a sleek, modern design with glowing edges. The overall atmosphere is high-tech and vibrant, with a mix of dark and neon colors." \
  --sample-steps 5 --show
  ```

  Once the command completes, the generated image will appear in the default viewer. You can experiment with the prompt and CLI options to customize the output.

  ![Generated Image](docs/assets/quickstart-minion.png)

  3. Open `http://myserver` in the browser to access the GPUStack UI. Log in to GPUStack with username `admin` and the default password. You can run the following command to get the password for the default setup:

  **Linux or macOS**

  ```bash
  cat /var/lib/gpustack/initial_admin_password
  ```

  **Windows**

  ```powershell
  Get-Content -Path "$env:APPDATA\gpustack\initial_admin_password" -Raw
  ```

  4. Click `Playground` in the navigation menu. Now you can chat with the LLM in the UI playground.

  ![Playground Screenshot](docs/assets/playground-screenshot.png)

  5. Click `API Keys` in the navigation menu, then click the `New API Key` button.

  6. Fill in the `Name` and click the `Save` button.

  7. Copy the generated API key and save it somewhere safe. Please note that you can only see it once on creation.

  8. Now you can use the API key to access the OpenAI-compatible API. For example, use curl as the following:

  ```bash
  export GPUSTACK_API_KEY=myapikey
  curl http://myserver/v1-openai/chat/completions \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $GPUSTACK_API_KEY" \
    -d '{
      "model": "llama3.2",
      "messages": [
        {
          "role": "system",
          "content": "You are a helpful assistant."
        },
        {
          "role": "user",
          "content": "Hello!"
        }
      ],
      "stream": true
    }'
  ```



  - [x] macOS
  - [x] Linux
  - [x] Windows



  - [x] Apple Metal (M-series chips)
  - [x] NVIDIA CUDA ([Compute Capability](https://developer.nvidia.com/cuda-gpus) 6.0 and above)
  - [x] Ascend CANN
  - [x] Moore Threads MUSA

  We plan to support the following accelerators in future releases.

  - [ ] AMD ROCm
  - [ ] Intel oneAPI
  - [ ] Qualcomm AI Engine



  GPUStack uses [llama-box](https://github.com/gpustack/llama-box) (bundled [llama.cpp](https://github.com/ggerganov/llama.cpp) and [stable-diffusion.cpp](https://github.com/leejet/stable-diffusion.cpp) server), [vLLM](https://github.com/vllm-project/vllm) and [vox-box](https://github.com/gpustack/vox-box) as the backends and supports a wide range of models. Models from the following sources are supported:

  1. [Hugging Face](https://huggingface.co/)

  2. [ModelScope](https://modelscope.cn/)

  3. [Ollama Library](https://ollama.com/library)

  4. Local File Path



  | **Category**                     | **Models**                                                                                                                                                                                                                                                                                                                                   |
  | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  | **Large Language Models(LLMs)**  | [Qwen](https://huggingface.co/models?search=Qwen/Qwen), [LLaMA](https://huggingface.co/meta-llama), [Mistral](https://huggingface.co/mistralai), [Deepseek](https://huggingface.co/models?search=deepseek-ai/deepseek), [Phi](https://huggingface.co/models?search=microsoft/phi), [Yi](https://huggingface.co/models?search=01-ai/Yi)       |
  | **Vision Language Models(VLMs)** | [Llama3.2-Vision](https://huggingface.co/models?pipeline_tag=image-text-to-text&search=llama3.2), [Pixtral](https://huggingface.co/models?search=pixtral) , [Qwen2-VL](https://huggingface.co/models?search=Qwen/Qwen2-VL), [LLaVA](https://huggingface.co/models?search=llava), [InternVL2](https://huggingface.co/models?search=internvl2) |
  | **Diffusion Models**             | [Stable Diffusion](https://huggingface.co/models?search=gpustack/stable-diffusion), [FLUX](https://huggingface.co/models?search=gpustack/flux)                                                                                                                                                                                               |
  | **Rerankers**                    | [GTE](https://huggingface.co/gpustack/gte-multilingual-reranker-base-GGUF), [BCE](https://huggingface.co/gpustack/bce-reranker-base_v1-GGUF), [BGE](https://huggingface.co/gpustack/bge-reranker-v2-m3-GGUF), [Jina](https://huggingface.co/models?search=gpustack/jina)                                                                     |
  | **Audio Models**                 | [Whisper](https://huggingface.co/models?search=Systran/faster) (speech-to-text), [CosyVoice](https://huggingface.co/models?search=FunAudioLLM/CosyVoice) (text-to-speech)                                                                                                                                                                    |

  For full list of supported models, please refer to the supported models section in the [inference backends](https://docs.gpustack.ai/latest/user-guide/inference-backends/) documentation.



  GPUStack serves the following OpenAI compatible APIs under the `/v1-openai` path:

  - [x] [List Models](https://platform.openai.com/docs/api-reference/models/list)
  - [x] [Create Completion](https://platform.openai.com/docs/api-reference/completions/create)
  - [x] [Create Chat Completion](https://platform.openai.com/docs/api-reference/chat/create)
  - [x] [Create Embeddings](https://platform.openai.com/docs/api-reference/embeddings/create)
  - [x] [Create Image](https://platform.openai.com/docs/api-reference/images/create)
  - [x] [Create Image Edit](https://platform.openai.com/docs/api-reference/images/createEdit)
  - [x] [Create Speech](https://platform.openai.com/docs/api-reference/audio/createSpeech)
  - [x] [Create Transcription](https://platform.openai.com/docs/api-reference/audio/createTranscription)

  For example, you can use the official [OpenAI Python API library](https://github.com/openai/openai-python) to consume the APIs:

  ```python
  from openai import OpenAI
  client = OpenAI(base_url="http://myserver/v1-openai", api_key="myapikey")

  completion = client.chat.completions.create(
    model="llama3.2",
    messages=[
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "Hello!"}
    ]
  )

  print(completion.choices[0].message)
  ```

  GPUStack users can generate their own API keys in the UI.



  Please see the [official docs site](https://docs.gpustack.ai) for complete documentation.



  1. Install `python 3.10+`.

  2. Run `make build`.

  You can find the built wheel package in `dist` directory.



  Please read the [Contributing Guide](./docs/contributing.md) if you're interested in contributing to GPUStack.



  Copyright (c) 2024 The GPUStack authors

  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at [LICENSE](./LICENSE) file for details.

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.


