semvec/pypi-packages huggingface dataset:
controlgraph 0.7.1
Generate build order graph from directory of debian packaging repositories
Requires Python: >=3.5,<4

# controlgraph

[![PyPI version](https://badge.fury.io/py/controlgraph.svg)](https://pypi.org/project/controlgraph/)
[![Build status](https://badge.buildkite.com/81c4e486b5f9ff5d3bf3f3da820201cefad4965207f4e2a8c2.svg)](https://buildkite.com/opx/opx-infra-controlgraph)

controlgraph is a directed graph which can be traversed to enable parallelized Debian package builds.

From the available directories with valid Debian packaging, a graph with directories (representing source packages) for nodes and build dependencies for edges is produced. The reverse of this graph can traversed with a breadth-first search to build in dependency order.

`controlgraph` is a program which returns the controlgraph for a directory to build, in linear or dot format.

## Installation

```bash
pip3 install controlgraph
```

## Library Usage

```python3
import sys

from pathlib import Path

import controlgraph
import networkx as nx

# get all directories
dirs = [p for p in Path.cwd().iterdir() if p.is_dir()]

# get map of local binary packages to locally-available source build dependencies
pkgs = controlgraph.parse_all_controlfiles(dirs)

# generate build dependency graph from map
dep_graph = controlgraph.graph(pkgs)

# print full dot graph
nx.nx_pydot.write_dot(dep_graph, sys.stdout)

# print linear order from depth-first search
print(" ".join(list(nx.dfs_postorder_nodes(dep_graph))))
```

Output

```
strict digraph  {
"opx-nas-daemon";
"opx-common-utils";
"opx-cps";
"opx-logging";
"opx-nas-acl";
"opx-sdi-sys";
"opx-nas-daemon" -> "opx-common-utils";
"opx-nas-daemon" -> "opx-cps";
"opx-nas-daemon" -> "opx-logging";
"opx-nas-daemon" -> "opx-nas-acl";
"opx-common-utils" -> "opx-logging";
"opx-cps" -> "opx-common-utils";
"opx-cps" -> "opx-logging";
"opx-nas-acl" -> "opx-common-utils";
"opx-nas-acl" -> "opx-cps";
"opx-nas-acl" -> "opx-logging";
"opx-sdi-sys" -> "opx-common-utils";
"opx-sdi-sys" -> "opx-logging";
}

opx-logging opx-common-utils opx-cps opx-nas-acl opx-nas-daemon opx-sdi-sys
```

## CLI Usage

With one or more directories present, run `controlgraph`.

```bash
$ for r in opx-nas-acl opx-nas-daemon opx-alarm opx-logging opx-common-utils; do
    git clone "https://github.com/open-switch/$r"
  done

$ controlgraph
opx-alarm opx-logging opx-common-utils opx-nas-acl opx-nas-daemon

$ controlgraph --graph
strict digraph  {
"opx-alarm";
"opx-nas-daemon";
"opx-common-utils";
"opx-logging";
"opx-nas-acl";
"opx-nas-daemon" -> "opx-common-utils";
"opx-nas-daemon" -> "opx-logging";
"opx-nas-daemon" -> "opx-nas-acl";
"opx-common-utils" -> "opx-logging";
"opx-nas-acl" -> "opx-common-utils";
"opx-nas-acl" -> "opx-logging";
}
```
j2skaffold 0.1.0
Simple wrapper around skaffold for rendering skaffold.yaml

============
 j2skaffold
============

A simple `skaffold <https://github.com/GoogleContainerTools/skaffold>`_ wrapper
with support for `jinja2 <http://jinja.pocoo.org>`_ templating.

Status
======

.. image:: https://secure.travis-ci.org/jkozera/j2skaffold.png?branch=master
   :target: http://travis-ci.org/jkozera/j2skaffold
.. image:: https://coveralls.io/repos/jkozera/j2skaffold/badge.png?branch=master
   :target: https://coveralls.io/r/jkozera/j2skaffold?branch=master
.. image:: https://img.shields.io/pypi/v/j2skaffold.svg
   :target: https://pypi.python.org/pypi/j2skaffold
.. image:: https://readthedocs.org/projects/j2skaffold/badge/?version=latest
   :target: https://readthedocs.org/projects/j2skaffold/?badge=latest
   :alt: Documentation Status


Requirements
============

* Python 2.7 or Python 3.3+ or PyPy 2.4.0+

Setup
=====

::

  $ python -m pip install --user j2skaffold
  or
  (venv)$ python -m pip install j2skaffold

Usage
=====

::

  $ j2skaffold dev

will run ``skaffold dev`` after rendering the ``skaffold.jinja2`` file from the
current directory.

::

  $ j2skaffold dev --keep-yaml

will do the same, keeping the rendered ``skaffold.yaml`` file. (Useful for debugging.)


The following special variables are available:

- ``skaffold_command`` (``dev``, ``build``, etc.)
- ``current_profile`` (value of the ``-p`` argument)

The following special yaml key can be used:

- ``_set_profile: [name]`` - sets the current profile using the ``-p``
  argument. Should be always wrapped inside some
  ``{% if not current_profile %}``, otherwise it will get passed through,
  and ``skaffold`` will fail with:

::

  FATA[0000] creating runner: reading configuration: parsing skaffold config: parsing skaffold config: yaml: unmarshal errors:
  line 2: field _set_profile not found in type v1alpha3.SkaffoldConfig


Example ``skaffold.jinja2`` demonstrating all the available features:

::

  {% if skaffold_command == 'dev' and not current_profile %}
  _set_profile: dev
  {% endif %}
  apiVersion: skaffold/v1alpha3
  kind: Config
  build:
    artifacts:
    - imageName: gcr.io/k8s-skaffold/skaffold-example-{{ current_profile }}
  deploy:
    kubectl:
      manifests:
        - k8s-*
  profiles:
  {% for profile in ['dev', 'production'] %}
    - name: {{ profile }}
      # ... use any jinja2 syntax
  {% endfor %}

ChangeLog
=========

0.1.0 (2018-10-08)
------------------

* Initial release.