[](https://pypi.org/project/ntc-templates-elinpf)
[](https://github.com/Elinpf/net_inspect)
[](https://github.com/Elinpf/ntc-templates/stargazers)
说明
===
本仓库为主仓的分支，主要提供中国大陆常用网络设备textFSM。
*需要注意的是，新华三`H3C`在海外使用的是`hp`，所以在此仓库中的`hp_comware`是指的`H3C`的路由交换软件平台。*
为了避免与原包的冲突，请在使用前先删除原包。
```
pip uninstall ntc_templates
```
本仓库的安装方法
```
pip install ntc_templates_elinpf
```
textfsm的开发难免遇到一些不兼容的问题，有使用上的任何问题，欢迎提issue。
固定release时间为工作日的周五，大家可以经常更新以获得更好的体验。
更新方法：
```
pip install ntc_templates_elinpf -U
```
## 新增功能
### 读取外部模板
在原有的基础上，新增加了支持外部模板的功能：
```py
def parse_output(platform=None, command=None, data=None, template_dir: str = None):
```
需要注意的是，`template_dir`参数需要指定一个文件夹，而不是一个文件。
文件夹中必须包含`index`文件，并且文件开头必须为以下内容:
```text
Template, Hostname, Platform, Command
```
### 增加返回clitable的方法
```py
def get_clitable(platform=None, command=None, template_dir: str = None) -> clitable.CliTable:
```
这个方法的目的是可以获取到模板的`clitable`对象，方便进行一些自定义的操作。
## 关于开发textfsm
我重写了原有的`development_scripts.py`。使它更符合个人的开发习惯。
```txt
usage: development_script.py [-h] [-v VENDOR] [-c COMMAND] [-g] [-i INDEX] [-b] [-t] [-y] [-s]
自动生成textfsm和所需raw文件, 方便对textfsm进行测试
optional arguments:
-h, --help show this help message and exit
-v VENDOR, --vendor VENDOR
设备厂商
-c COMMAND, --command COMMAND
设备命令
-g, --generate 生成测试文件
-i INDEX, --index INDEX
多raw文件的索引，从2开始
-b, --blank 对textfsm文件进行空格替换
-t, --test 对textfsm进行测试
-y, --yml 生成yml文件
-s, --short 通过短命令生成index文件需要的条目
```
### 举例
假设以华为厂家 `huawei_vrp` 路由交换软件平台的`display version`命令进行开发测试。
1. 首先创建所需要的模板文件`textfsm`和作为测试用到的解析文件`raw`
```bash
python ./development_script.py -v 'huawei_vrp' -c 'display version' -g
```
2. 编写`textfsm`和测试时使用的命令输出, 此时需要对`textfsm` 的Rule中的空格替换成`\s+`防止意外
```bash
python ./development_script.py -v 'huawei_vrp' -c 'display version' -b
```
3. 如果有多个测试用例，可以使用`-i` 再次进行创建`raw`文件
```bash
python ./development_script.py -v 'huawei_vrp' -c 'display version' -i 2 -g
```
4. 对编写的内容进行测试
```bash
python ./development_script.py -v 'huawei_vrp' -c 'display version' -t
```
5. 对于多个测试用例， 也可以使用`-i`进行单独测试
```bash
python ./development_script.py -v 'huawei_vrp' -c 'display version' -i 2 -t
```
6. 测试结果符合预期后，生成全部`yml`文件
```bash
python ./development_script.py -v 'huawei_vrp' -c 'display version' -y
```
7. 生成index中的条目
```bash
python ./development_script.py -v 'huawei_vrp' -c 'display version' -s
>> input shortest cmd: dis ver
>> huawei_vrp_display_version.textfsm, .*, huawei_vrp, dis[[play]] ver[[sion]]
```
将生成的条目复制到`index`文件中即可。
## 贡献者 ✨
<div>
<a href="https://github.com/Elinpf">
<img src="https://avatars.githubusercontent.com/u/18662258?v=4" alt="Elinpf" width="50" height="50"></a>
<a href="https://github.com/chaojifeixia-007">
<img src="https://avatars.githubusercontent.com/u/67045217?v=4" alt="chaojifeixia-007" width="50" height="50"></a>
<a href="https://github.com/singvis">
<img src="https://avatars.githubusercontent.com/u/41747912?v=4" alt="singvis" width="50" height="50"></a>
<a href="https://github.com/20049941">
<img src="https://avatars.githubusercontent.com/u/83266374?v=4" alt="20049941" width="50" height="50"></a>
<a href="https://github.com/MisterProblems">
<img src="https://avatars.githubusercontent.com/u/75603060?v=4" alt="MisterProblems" width="50" height="50"></a>
<a href="https://github.com/NetDevOPS2">
<img src="https://avatars.githubusercontent.com/u/18698531?v=4" alt="NetDevOPS2" width="50" height="50"></a>
</div>
---
以下内容为主仓库`README`
NTC TEMPLATES
=============
Repository of TextFSM Templates for Network Devices, and Python wrapper for TextFSM's CliTable.
[TextFSM](https://github.com/google/textfsm/wiki) is a project built by Google that takes CLI string output and passes each line through a series of regular expressions until it finds a match. The regular expressions use named capture groups to build a text table out of the significant text. The names of the capture groups are used as column headers, and the captured values are stored as rows in the table.
This project provides a large collection of TextFSM Templates (text parsers) for a variety of Networking Vendors. In addition to the templates, there is a function that will convert the CLI output into a CliTable object; the resulting text table is converted into a list of dictionaries mapping the column headers with each row in the table.
> As of v2.0.0, this project uses [Poetry](https://python-poetry.org/) for packaging and distribution. In order to use poetry, the `templates` directory has been moved to `ntc_templates/templates`
Installation and Usage
----------------------
The project can be installed using either Git + Poetry or PyPI.
#### Git
```shell
$ git clone git@github.com:networktocode/ntc-templates.git
$
# Optional steps to install ntc-templates as a python package
$ poetry install
$
```
#### PyPI
```shell
$ pip install ntc_templates
$
```
#### Usage
```python
>>> from ntc_templates.parse import parse_output
>>> vlan_output = (
"VLAN Name Status Ports\n"
"---- -------------------------------- --------- -------------------------------\n"
"1 default active Gi0/1\n"
"10 Management active \n"
"50 VLan50 active Fa0/1, Fa0/2, Fa0/3, Fa0/4, Fa0/5,\n"
" Fa0/6, Fa0/7, Fa0/8\n"
)
>>> vlan_parsed = parse_output(platform="cisco_ios", command="show vlan", data=vlan_output)
>>> vlan_parsed
[
{
'vlan_id': '1',
'name': 'default',
'status': 'active',
'interfaces': ['Gi0/1']
},
{
'vlan_id': '10',
'name': 'Management',
'status': 'active',
'interfaces': []
},
{
'vlan_id': '50',
'name': 'VLan50', 'status': 'active',
'interfaces': ['Fa0/1', 'Fa0/2', 'Fa0/3', 'Fa0/4', 'Fa0/5', 'Fa0/6', 'Fa0/7', 'Fa0/8']
}
]
>>>
```
### Define Custom Templates Directory
To use a custom templates directory set the environmental variable `NTC_TEMPLATES_DIR`.
**Requirements**
1. `index` file needs to be defined with standard structure. [See](#Index-File)
2. Each custom template should be defined.
To manaully set variable:
```shell
export NTC_TEMPLATES_DIR=/path/to/new/location/templates
```
To set within your program:
```python
import os
os.environ["NTC_TEMPLATES_DIR"] = "/path/to/new/templates/location/templates"
```
Contributing
------------
Pull requests are welcomed and automatically built and tested through TravisCI.
### New Templates
To contribute new templates, each new pull request must include the following:
- TextFSM template
- Modified version of the **index** file
- Tests
* Raw version of text to be parsed
* YAML file containing the expected parsed dictionary
#### TextFSM Template
TextFSM templates should be placed in the `./templates` directory and should adhere to the following NTC-Templates style.
The TextFSM template name should be in the following format:
##### Naming
The template should be named using: `{{ vendor_os }}_{{ command_with_underscores }}.textfsm`
> Ex: cisco_ios_show_cdp_neighbors.textfsm
Note: The vendor name must be valid from the [os_choices](https://github.com/networktocode/ntc-templates/blob/master/tests/test_index_order.py#L59) tests, which is primarily based on [Netmiko](https://github.com/ktbyers/netmiko/tree/master/netmiko) list of supported vendors. New vendors added should adhere to **vendor_os**.
> Ex: vmware_nsx
##### Values
The capture group names should be in UPPERCASE.
An example of the proper format is shown below.
```
Value TIME (\d+:\d+:\d+)
Value TIMEZONE (\S+)
Value DAYWEEK (\w+)
Value MONTH (\d+)
Value DAY (\d+)
Value YEAR (\d+)
Start
^${TIME}\s+${TIMEZONE}\s+${DAYWEEK}\s+${DAY}/${MONTH}/${YEAR} -> Record
^. -> Error
```
##### States
If the raw output has a heading, the `Start` state should match on the column headings and then transition to another state that will match the device's output table with the capture groups. This helps ensure the regex patterns for the capture groups are attempting to match the correct information, and allows templates to easily add additional States for tables that have different headings.
Example:
*Raw Output*
```
... omitted
Network Next Hop Metric LocPrf Weight Path
*> 111.111.111.111/32 112.112.112.112 4294967295 4294967295 65535 1000 1000 1000 i
```
*Sample Template*
```
Start
# Checking for header
^\s*Network\s+Next(?:\s+|-)[Hh]op\s+Metric\s+LocPrf\s+Weight\s+Path\s*$$ -> BGPTable
BGPTable
... omitted
```
Each **state** should end with `^. -> Error`. This helps to ensure we're accounting for every line within the raw output for the command. This doesn't mean we have to capture all the data as a **Value**, but we do have to account for it. In addition, it is also good to provide an expression to match blank lines, `^\s*$$`
An example would be the following raw output:
```
NAME: "3640 chassis", DESCR: "3640 chassis"
PID: , VID: 0xFF, SN: FF1045C5
```
The template would be the following:
```
Value NAME (.*)
Value DESCRIPTION (.*)
Start
^NAME:\s+"${NAME}",\s*DESCR:\s+"${DESCRIPTION}"
^PID:\s*,\s*VID:\s*\S+,\s*SN:\s*\S+
^\s*$$
^. -> Error
```
Taking a look at the example template above, you notice that we're using **\s*** and **\s+**. These are the preferred way to match space characters, and should be used over the literal space character. For example, `This\s+is\s+preferred\s*$$` vs `This is not preferred$$`
- **\s*** accounts for zero or more spaces (use when the output may or may not have a space between characters)
- **\s+** accounts for one or more spaces (use when output will have a space, but could have more than one space)
#### Index File
The Index file binds the templates to the commands being run. Special care has been taken on ordering, as there is potential for issues. e.g. `show ip route` picking up for `show ip router vrf <vrf-name>`. We have used a combination of ordering, as defined:
- OS in alphabetical order
- Template name in length order (longest to shortest)
- When length is the same, use alphabetical order of command name
- Keep space between OS's
Example:
```
Template, Hostname, Platform, Command
# same os, same length, used alphabetical order of command name
arista_eos_show_mlag.textfsm, .*, arista_eos, sh[[ow]] ml[[ag]]
arista_eos_show_vlan.textfsm, .*, arista_eos, sh[[ow]] vl[[an]]
# os in alphabetical order and space between cisco_asa and arista_eos
cisco_asa_dir.textfsm, .*, cisco_asa, dir
# same os, template name length different and space between cisco_asa and cisco_ios
cisco_ios_show_capability_feature_routing.textfsm, .*, cisco_ios, sh[[ow]] cap[[ability]] f[[eature]] r[[outing]]
cisco_ios_show_interface_transceiver.textfsm, .*, cisco_ios, sh[[ow]] int[[erface]] trans[[ceiver]]
cisco_ios_show_cdp_neighbors_detail.textfsm, .*, cisco_ios, sh[[ow]] c[[dp]] neig[[hbors]] det[[ail]]
```
#### Tests
Tests will be located in `./tests` with the following hierarchy:
- `./tests/{{ vendor_os }}/{{ command_name }}/`
The `{{ command_name }}` directory should include the `.raw` file that includes the raw output of the command to be parsed, and the `.yml` file of the returned structured data.
```bash
$ ls tests/cisco_ios/show_clock/
cisco_ios_show_clock.yml
cisco_ios_show_clock.raw
$
```
##### Raw version of input text
The raw text file should contain **only** the output of the CLI command to be parsed. It should **not** contain the CLI command itself.
An example of the proper format is shown below:
```bash
$ cat tests/cisco_ios/show_clock/cisco_ios_show_clock.raw
*18:57:38.347 UTC Mon Oct 19 2015
$
```
##### YAML file containing expected parsed dictionary
The parsed file should match the data that is returned from the `parse_output` function discussed in the beginning. Dictionary keys should be in lowercase.
The parsed text file should be placed in a directory in the `./tests` directory with the same name as the template file but replace `.textfsm` file extension with `.yml`. The raw text file and the parsed text file should be in the same directory.
**ex. ./tests/cisco_ios/show_clock/**
There are available helpers to create the parsed file in the correct format (See _Development Helper Scripts_ below).
An example of the proper format is shown below:
```bash
$ cat ./tests/cisco_ios/show_clock/cisco_ios_show_clock.yml
---
parsed_sample:
- time: "18:57:38.347"
timezone: "UTC"
dayweek: "Mon"
month: "Oct"
day: "19"
year: "2015"
$
```
Multiple `raw` and `parsed` files are supported per directory, and are encouraged, as there are differences depending on version, length, etc. Additional test files and more real life data helps ensure backwards compatibility is maintained as each template is updated and merged into the repo.
All YAML files must adhere to the YAML standards defined in the `.yamllint` file in the root directory. Yamllint provides thorough documentation of their configuration settings [here](https://yamllint.readthedocs.io/en/stable/rules.html).
##### Development Helper Scripts
A cli utility is provided to assist with properly building the parsed files. This utility depends on some packages listed in the dev install requirements; see _Install and Usage_ for directions on installing the dev requirements. All arguments that can be passed to the script are mutually exclusive (i.e. you can only pass one argument). The file can be made executable with the `chmod +x development_scripts.py` command. The arguments are:
* `-y`: Takes the path to a YAML file and ensures that the file adheres to the .yamllint settings
* `-yd`: Takes a glob path to a directory or directories that will ensure all files ending in `.yml` adhere to the .yamllint settings
* `-c`: Takes the path to a `.raw` file, and generates the parsed data and saves the results adjacent to the `.raw` file following the defined standards in .yamllint.
* `-cd`: Takes a glob path to a directory or directories containing `.raw` files, and creates the appropriate parsed files in the appropriate directory.
The `-y` and `-yd` arguments are designed to allow developers to generate the expected parsed file how they want, and ensure that the formatting adheres to the defined standard for this project.
The `-c` and `-cd` arguments use `ntc_templates.parse.parse_output()` to generate the parsed data; this means that you can use these arguments to auto-generate the test `.yml` file(s) for new templates; just be sure that the template's parsing behavior meets expectations. In order for the data to be parsed, the template must be placed in `ntc_templates/templates/` and the `ntc_templates/templates/index` file must be updated to correctly point to the template file(s).
```bash
$ ./development_scripts.py -yd tests/cisco_ios/show_mac-address-table
tests/cisco_ios/show_mac-address-table/cisco_ios_show_mac-address-table2.yml
tests/cisco_ios/show_mac-address-table/cisco_ios_show_mac-address-table3.yml
tests/cisco_ios/show_mac-address-table/cisco_ios_show_mac-address-table5.yml
tests/cisco_ios/show_mac-address-table/cisco_ios_show_mac-address-table4.yml
tests/cisco_ios/show_mac-address-table/cisco_ios_show_mac-address-table.yml
$
$ ls tests/arista_eos/show_version/
arista_eos_show_version.raw
$
$ ./development_scripts.py -c tests/arista_eos/show_version/arista_eos_show_version.txt
$ ls tests/arista_eos/show_version/
arista_eos_show_version.raw arista_eos_show_version.yml
$
```
### Updating/Fixing Existing Templates
When either fixing a bug within a template or adding additional **Values** to be captured, additional test files should be added to ensure backwards compatibility and that the new data is being parsed correctly.
To add additional raw/parsed tests for a command:
- Navigate to `./tests/{{ vendor_os }}/{{ command_name }}/`
- Create new `.raw` and `.yml` files within the directory, preferrably with a name identifying why the data is unique:
* Existing raw: `./tests/cisco_ios/show_version/cisco_ios_show_version.raw`
* New raw: `./tests/cisco_ios/show_version/cisco_ios_show_version_stack_platforms.raw`
* Existing parsed: `./tests/cisco_ios/show_version/cisco_ios_show_version.yml`
* New parsed: `./tests/cisco_ios/show_version/cisco_ios_show_version_stack_platforms.yml`
#### Testing
You can test your changes locally within your Git branch before submitting a PR. If you do not have **tox** already installed, you can do that using pip or your systems package manager. Tox should be ran inside the **ntc-templates** root directory. The tox file is configured to run against python3.6,python3.7, and python3.8, if none/some of those python versions are unavailable **tox** will skip them. The tox.ini file can be updated with an available Python version.
```bash
$ tox
GLOB sdist-make: /home/travis/build/networktocode/ntc-templates/setup.py
py36 create: /home/travis/build/networktocode/ntc-templates/.tox/py36
py36 inst: /home/travis/build/networktocode/ntc-templates/.tox/.tmp/package/1/ntc_templates-1.6.0.zip
py36 installed: appdirs==1.4.4,attrs==20.3.0,black==20.8b1,click==7.1.2,dataclasses==0.8,future==0.18.2,importlib-metadata==3.7.0,iniconfig==1.1.1,mypy-extensions==0.4.3,ntc-templates==1.6.0,packaging==20.9,pathspec==0.8.1,pluggy==0.13.1,py==1.10.0,pyparsing==2.4.7,pytest==6.2.2,PyYAML==5.4.1,regex==2020.11.13,ruamel.yaml==0.16.12,ruamel.yaml.clib==0.2.2,six==1.15.0,textfsm==1.1.0,toml==0.10.2,typed-ast==1.4.2,typing-extensions==3.7.4.3,yamllint==1.26.0,zipp==3.4.0
py36 run-test-pre: PYTHONHASHSEED='4147443973'
py36 run-test: commands[0] | black ./ --diff --check
All done! ✨ 🍰 ✨
9 files would be left unchanged.
py36 run-test: commands[1] | yamllint tests/
py36 run-test: commands[2] | pytest -vv
============================= test session starts ==============================
platform linux -- Python 3.6.7, pytest-6.2.2, py-1.10.0, pluggy-0.13.1 -- /home/travis/build/networktocode/ntc-templates/.tox/py36/bin/python
cachedir: .tox/py36/.pytest_cache
rootdir: /home/travis/build/networktocode/ntc-templates
collected 1065 items
tests/test_development_scripts.py::test_ensure_spacing_for_multiline_comment PASSED [ 0%]
tests/test_development_scripts.py::test_ensure_space_after_octothorpe PASSED [ 0%]
tests/test_development_scripts.py::test_ensure_space_comments PASSED [ 0%]
tests/test_development_scripts.py::test_update_yaml_comments PASSED [ 0%]
tests/test_development_scripts.py::test_transform_file PASSED [ 0%]
tests/test_testcases_exists.py::test_verify_parsed_and_reference_data_exists[tests/yamaha/show_environment] PASSED [ 99%]
tests/test_testcases_exists.py::test_verify_parsed_and_reference_data_exists[tests/yamaha/show_ip_route] PASSED [100%]
============================ 1065 passed in 22.59s =============================
py37 create: /home/travis/build/networktocode/ntc-templates/.tox/py37
SKIPPED: InterpreterNotFound: python3.7
py38 create: /home/travis/build/networktocode/ntc-templates/.tox/py38
SKIPPED: InterpreterNotFound: python3.8
___________________________________ summary ____________________________________
py36: commands succeeded
SKIPPED: py37: InterpreterNotFound: python3.7
SKIPPED: py38: InterpreterNotFound: python3.8
congratulations :)
The command "tox" exited with 0.
Done. Your build exited with 0.
$
```
Questions
---------
For any questions or comments, please feel free to swing by the [networktocode slack channel](https://networktocode.slack.com).
Sign up [here](http://slack.networktocode.com/)
CHANGELOG
---------
Changelog should be generated using [github_changelog_generator](https://github.com/github-changelog-generator/github-changelog-generator)
FAQ
---
From an outsiders view, some design choices, requirements, and testing procedures can seem arbitrary. The following list of FAQ is intended to
help provide context and better guide users and contributors of ntc-templates.
_Why is there a requirement to use `Error` in every template?_
Ensuring that the textfsm template can account for every line is the only method to ensure that data was not accidentally missed. Take the following example. Initially we account for status to be:
`Value STATUS (up|down)`
Given the result of:
```
Interface Status Protocol Description
Gi0/0/1 admin down down
Gi0/0/2 up up ISP Connection
Gi0/0/3 down down
```
The output would miss the G0/0/1 interface, since the `STATUS` of `admin down` not known. If this was a low percentage use case, it can go
undetected, and result in incorrect information being returned. Instead, by ensuring that we fail fast, an `Error` is raised and hopefully
GitHub Issue is put in.
_Then why isn't `Error` used in all templates?_
Initially the controls were not as strong, so many templates were put in until issues like the previous became an issue.
_Does the project support requests for additional templates or additional data in an existing template?_
We are no longer considering additional template requests at this time. The project has existed for over 5 years (initially within ntc-ansible)
and nearly 200 template at this point any additional requests are essentially edge use cases. Meaning, for five years of usage, no one else
has asked for this feature. There is a limited maintainers who primarily use their free time to maintain the project.
_Are you open to adding maintainers to the project?_
Yes, we would consider giving a proven member of the project and community maintainer rights. Please inquiry emailing info@networktocode.com.
_I simply want to add my template to the project, I do not want to add all of these tests and controls, can I just do so?_
Short answer no, from an outsiders point of view the contributor requirements may seem overly complex, however features added by engineers
rarely come back to support them. The burden of support is on the maintainers and a certain level of quality assurance is required for that to
happen. That includes updating the index file appropriately and adding proper raw and expected value files.
_Why don't you grab all of the data in the template?_
There is no intention for ntc-templates to become feature complete, some of the data is less interesting, or can be better understood from
other commands. This is actually an area where the project chose to be loose, as we do not want to over-burden the contributor. If you feel
that the additional data should be added, you are welcome to add the feature, but it would not be considered a bug, and thus not supported by
the maintainers of the this project.
_Why does the index order matter?_
The "greediness" of the template match ensures that there longest matches first. For example, if `show ip ospf` was above `show ip ospf database`, the `show ip ospf` template would be used in both cases. The additional steps are because of general programmatic hygiene.
_Will you accept my template if I create it?_
In most cases, yes. However, there are a few edge cases. For example if requesting to add a `show cdp neighbors` when there is already a `show cdp neighbors details` template created. That is additional complexity added to the project with little value.
_Why was my issue closed?_
The most likely reasons are:
* Did not follow the Issue creation template.
* Did not provide the data required to act upon the request.
* A prolonged time with no response.
_What is meant that this is a parsing project, not a data modeling project?_
The project intends to parse, meaning post processing is assumed in order to normalize the data. This project does not intend to solve that
problem set. This is often noted in keys being different between the same command on multiple OS's. This was not intentional as at first there was not strict enforcement. That being said, there is no intention to retrofit this use case for the above stated reasons. This use case is
best handled in post processing.
_I have never submitted a Pull Request before, how do I do so?_
This is outside the scope of this project, but this [video](https://www.youtube.com/watch?v=rgbCcBNZcdQ) should provide the instructions on
how to do so.
_Does this work on windows?_
Based on this [PR](https://github.com/networktocode/ntc-templates/pull/672) it should, however this is not a supported option. We are willing
to take in qualified Pull Requests to have the feature, but have no intention of actively supporting.
_Can you provide general guidance?_
This is best handled via real time communication. Feel free to join our slack community (sign up information above) and reach out on the #networktocode channel. Please be aware of timezones, downtimes, and help is performed based on goodwill and timing, and not guaranteed.
### Known Issues
#### Cannot import name clitable from textfsm
**ntc-templates** depends on **textfsm**, which hasn't published a source distribution to pypi in a while. See https://github.com/google/textfsm/issues/65.
This means that for users with a build chain that depends on source distributions only (i.e. no wheels), ntc-templates appears to have a bug:
```
File "/usr/local/Cellar/foo/version/libexec/lib/python3.7/site-packages/ntc_templates/parse.py", line 3, in <module>
from textfsm import clitable
ImportError: cannot import name 'clitable' from 'textfsm'
```
What's actually happening here is that textfsm provides a source distribution only up to version 0.4.1 (2018-04-09) but the ntc-templates code relies on the interface from version 1.1.0 (2019-07-24) which is only available as a wheel. So the way for users to fix this problem if they encounter it is to install textfsm 1.1.0.
`pip install textfsm==1.1.0`
> This was taken from https://github.com/networktocode/ntc-templates/issues/731
Raw data
{
"_id": null,
"home_page": "https://github.com/Elinpf/ntc-templates",
"name": "ntc-templates-elinpf",
"maintainer": "",
"docs_url": null,
"requires_python": ">=3.7,<4.0",
"maintainer_email": "",
"keywords": "",
"author": "Network to Code",
"author_email": "info@networktocode.com",
"download_url": "https://files.pythonhosted.org/packages/99/72/5c008d1a5df81c5bbb22fd2251482c69c222e3a9e953836dd6e83ee191c1/ntc_templates_elinpf-3.5.0.tar.gz",
"platform": null,
"description": "[](https://pypi.org/project/ntc-templates-elinpf)\n[](https://github.com/Elinpf/net_inspect)\n[](https://github.com/Elinpf/ntc-templates/stargazers)\n\n\u8bf4\u660e\n===\n\n\u672c\u4ed3\u5e93\u4e3a\u4e3b\u4ed3\u7684\u5206\u652f\uff0c\u4e3b\u8981\u63d0\u4f9b\u4e2d\u56fd\u5927\u9646\u5e38\u7528\u7f51\u7edc\u8bbe\u5907textFSM\u3002\n\n*\u9700\u8981\u6ce8\u610f\u7684\u662f\uff0c\u65b0\u534e\u4e09`H3C`\u5728\u6d77\u5916\u4f7f\u7528\u7684\u662f`hp`\uff0c\u6240\u4ee5\u5728\u6b64\u4ed3\u5e93\u4e2d\u7684`hp_comware`\u662f\u6307\u7684`H3C`\u7684\u8def\u7531\u4ea4\u6362\u8f6f\u4ef6\u5e73\u53f0\u3002*\n\n\u4e3a\u4e86\u907f\u514d\u4e0e\u539f\u5305\u7684\u51b2\u7a81\uff0c\u8bf7\u5728\u4f7f\u7528\u524d\u5148\u5220\u9664\u539f\u5305\u3002\n\n```\npip uninstall ntc_templates\n```\n\n\u672c\u4ed3\u5e93\u7684\u5b89\u88c5\u65b9\u6cd5\n\n```\npip install ntc_templates_elinpf\n```\n\ntextfsm\u7684\u5f00\u53d1\u96be\u514d\u9047\u5230\u4e00\u4e9b\u4e0d\u517c\u5bb9\u7684\u95ee\u9898\uff0c\u6709\u4f7f\u7528\u4e0a\u7684\u4efb\u4f55\u95ee\u9898\uff0c\u6b22\u8fce\u63d0issue\u3002\n\n\u56fa\u5b9arelease\u65f6\u95f4\u4e3a\u5de5\u4f5c\u65e5\u7684\u5468\u4e94\uff0c\u5927\u5bb6\u53ef\u4ee5\u7ecf\u5e38\u66f4\u65b0\u4ee5\u83b7\u5f97\u66f4\u597d\u7684\u4f53\u9a8c\u3002\n\n\u66f4\u65b0\u65b9\u6cd5\uff1a\n\n```\npip install ntc_templates_elinpf -U\n```\n\n## \u65b0\u589e\u529f\u80fd\n\n### \u8bfb\u53d6\u5916\u90e8\u6a21\u677f\n\n\u5728\u539f\u6709\u7684\u57fa\u7840\u4e0a\uff0c\u65b0\u589e\u52a0\u4e86\u652f\u6301\u5916\u90e8\u6a21\u677f\u7684\u529f\u80fd\uff1a\n\n```py\ndef parse_output(platform=None, command=None, data=None, template_dir: str = None):\n```\n\n\u9700\u8981\u6ce8\u610f\u7684\u662f\uff0c`template_dir`\u53c2\u6570\u9700\u8981\u6307\u5b9a\u4e00\u4e2a\u6587\u4ef6\u5939\uff0c\u800c\u4e0d\u662f\u4e00\u4e2a\u6587\u4ef6\u3002\n\u6587\u4ef6\u5939\u4e2d\u5fc5\u987b\u5305\u542b`index`\u6587\u4ef6\uff0c\u5e76\u4e14\u6587\u4ef6\u5f00\u5934\u5fc5\u987b\u4e3a\u4ee5\u4e0b\u5185\u5bb9:\n\n```text\nTemplate, Hostname, Platform, Command\n```\n\n### \u589e\u52a0\u8fd4\u56declitable\u7684\u65b9\u6cd5\n\n```py\ndef get_clitable(platform=None, command=None, template_dir: str = None) -> clitable.CliTable:\n```\n\n\u8fd9\u4e2a\u65b9\u6cd5\u7684\u76ee\u7684\u662f\u53ef\u4ee5\u83b7\u53d6\u5230\u6a21\u677f\u7684`clitable`\u5bf9\u8c61\uff0c\u65b9\u4fbf\u8fdb\u884c\u4e00\u4e9b\u81ea\u5b9a\u4e49\u7684\u64cd\u4f5c\u3002\n\n## \u5173\u4e8e\u5f00\u53d1textfsm\n\n\u6211\u91cd\u5199\u4e86\u539f\u6709\u7684`development_scripts.py`\u3002\u4f7f\u5b83\u66f4\u7b26\u5408\u4e2a\u4eba\u7684\u5f00\u53d1\u4e60\u60ef\u3002\n\n```txt\nusage: development_script.py [-h] [-v VENDOR] [-c COMMAND] [-g] [-i INDEX] [-b] [-t] [-y] [-s]\n\n\u81ea\u52a8\u751f\u6210textfsm\u548c\u6240\u9700raw\u6587\u4ef6, \u65b9\u4fbf\u5bf9textfsm\u8fdb\u884c\u6d4b\u8bd5\n\noptional arguments:\n -h, --help show this help message and exit\n -v VENDOR, --vendor VENDOR\n \u8bbe\u5907\u5382\u5546\n -c COMMAND, --command COMMAND\n \u8bbe\u5907\u547d\u4ee4\n -g, --generate \u751f\u6210\u6d4b\u8bd5\u6587\u4ef6\n -i INDEX, --index INDEX\n \u591araw\u6587\u4ef6\u7684\u7d22\u5f15\uff0c\u4ece2\u5f00\u59cb\n -b, --blank \u5bf9textfsm\u6587\u4ef6\u8fdb\u884c\u7a7a\u683c\u66ff\u6362\n -t, --test \u5bf9textfsm\u8fdb\u884c\u6d4b\u8bd5\n -y, --yml \u751f\u6210yml\u6587\u4ef6\n -s, --short \u901a\u8fc7\u77ed\u547d\u4ee4\u751f\u6210index\u6587\u4ef6\u9700\u8981\u7684\u6761\u76ee\n```\n\n### \u4e3e\u4f8b\n\n\u5047\u8bbe\u4ee5\u534e\u4e3a\u5382\u5bb6 `huawei_vrp` \u8def\u7531\u4ea4\u6362\u8f6f\u4ef6\u5e73\u53f0\u7684`display version`\u547d\u4ee4\u8fdb\u884c\u5f00\u53d1\u6d4b\u8bd5\u3002\n\n1. \u9996\u5148\u521b\u5efa\u6240\u9700\u8981\u7684\u6a21\u677f\u6587\u4ef6`textfsm`\u548c\u4f5c\u4e3a\u6d4b\u8bd5\u7528\u5230\u7684\u89e3\u6790\u6587\u4ef6`raw`\n\n```bash\npython ./development_script.py -v 'huawei_vrp' -c 'display version' -g\n```\n\n2. \u7f16\u5199`textfsm`\u548c\u6d4b\u8bd5\u65f6\u4f7f\u7528\u7684\u547d\u4ee4\u8f93\u51fa, \u6b64\u65f6\u9700\u8981\u5bf9`textfsm` \u7684Rule\u4e2d\u7684\u7a7a\u683c\u66ff\u6362\u6210`\\s+`\u9632\u6b62\u610f\u5916\n\n```bash\npython ./development_script.py -v 'huawei_vrp' -c 'display version' -b\n```\n\n3. \u5982\u679c\u6709\u591a\u4e2a\u6d4b\u8bd5\u7528\u4f8b\uff0c\u53ef\u4ee5\u4f7f\u7528`-i` \u518d\u6b21\u8fdb\u884c\u521b\u5efa`raw`\u6587\u4ef6\n\n```bash\npython ./development_script.py -v 'huawei_vrp' -c 'display version' -i 2 -g\n```\n\n4. \u5bf9\u7f16\u5199\u7684\u5185\u5bb9\u8fdb\u884c\u6d4b\u8bd5\n\n```bash\npython ./development_script.py -v 'huawei_vrp' -c 'display version' -t\n```\n\n5. \u5bf9\u4e8e\u591a\u4e2a\u6d4b\u8bd5\u7528\u4f8b\uff0c \u4e5f\u53ef\u4ee5\u4f7f\u7528`-i`\u8fdb\u884c\u5355\u72ec\u6d4b\u8bd5\n\n```bash\npython ./development_script.py -v 'huawei_vrp' -c 'display version' -i 2 -t\n```\n\n6. \u6d4b\u8bd5\u7ed3\u679c\u7b26\u5408\u9884\u671f\u540e\uff0c\u751f\u6210\u5168\u90e8`yml`\u6587\u4ef6\n\n```bash\npython ./development_script.py -v 'huawei_vrp' -c 'display version' -y\n```\n\n7. \u751f\u6210index\u4e2d\u7684\u6761\u76ee\n\n```bash\npython ./development_script.py -v 'huawei_vrp' -c 'display version' -s\n\n>> input shortest cmd: dis ver\n\n>> huawei_vrp_display_version.textfsm, .*, huawei_vrp, dis[[play]] ver[[sion]]\n```\n\n\u5c06\u751f\u6210\u7684\u6761\u76ee\u590d\u5236\u5230`index`\u6587\u4ef6\u4e2d\u5373\u53ef\u3002\n\n## \u8d21\u732e\u8005 \u2728\n\n<div>\n <a href=\"https://github.com/Elinpf\">\n <img src=\"https://avatars.githubusercontent.com/u/18662258?v=4\" alt=\"Elinpf\" width=\"50\" height=\"50\"></a>\n <a href=\"https://github.com/chaojifeixia-007\">\n <img src=\"https://avatars.githubusercontent.com/u/67045217?v=4\" alt=\"chaojifeixia-007\" width=\"50\" height=\"50\"></a>\n <a href=\"https://github.com/singvis\">\n <img src=\"https://avatars.githubusercontent.com/u/41747912?v=4\" alt=\"singvis\" width=\"50\" height=\"50\"></a>\n <a href=\"https://github.com/20049941\">\n <img src=\"https://avatars.githubusercontent.com/u/83266374?v=4\" alt=\"20049941\" width=\"50\" height=\"50\"></a>\n <a href=\"https://github.com/MisterProblems\">\n <img src=\"https://avatars.githubusercontent.com/u/75603060?v=4\" alt=\"MisterProblems\" width=\"50\" height=\"50\"></a>\n <a href=\"https://github.com/NetDevOPS2\">\n <img src=\"https://avatars.githubusercontent.com/u/18698531?v=4\" alt=\"NetDevOPS2\" width=\"50\" height=\"50\"></a>\n</div>\n\n---\n\n\u4ee5\u4e0b\u5185\u5bb9\u4e3a\u4e3b\u4ed3\u5e93`README`\n\n\n\n\nNTC TEMPLATES\n=============\n\nRepository of TextFSM Templates for Network Devices, and Python wrapper for TextFSM's CliTable.\n\n[TextFSM](https://github.com/google/textfsm/wiki) is a project built by Google that takes CLI string output and passes each line through a series of regular expressions until it finds a match. The regular expressions use named capture groups to build a text table out of the significant text. The names of the capture groups are used as column headers, and the captured values are stored as rows in the table.\n\nThis project provides a large collection of TextFSM Templates (text parsers) for a variety of Networking Vendors. In addition to the templates, there is a function that will convert the CLI output into a CliTable object; the resulting text table is converted into a list of dictionaries mapping the column headers with each row in the table.\n\n\n> As of v2.0.0, this project uses [Poetry](https://python-poetry.org/) for packaging and distribution. In order to use poetry, the `templates` directory has been moved to `ntc_templates/templates`\n\nInstallation and Usage\n----------------------\nThe project can be installed using either Git + Poetry or PyPI.\n\n#### Git\n\n```shell\n$ git clone git@github.com:networktocode/ntc-templates.git\n$ \n# Optional steps to install ntc-templates as a python package\n$ poetry install\n$ \n```\n\n#### PyPI\n\n```shell\n$ pip install ntc_templates\n$ \n```\n\n#### Usage\n\n```python\n>>> from ntc_templates.parse import parse_output\n>>> vlan_output = (\n \"VLAN Name Status Ports\\n\"\n \"---- -------------------------------- --------- -------------------------------\\n\"\n \"1 default active Gi0/1\\n\"\n \"10 Management active \\n\"\n \"50 VLan50 active Fa0/1, Fa0/2, Fa0/3, Fa0/4, Fa0/5,\\n\"\n \" Fa0/6, Fa0/7, Fa0/8\\n\"\n )\n>>> vlan_parsed = parse_output(platform=\"cisco_ios\", command=\"show vlan\", data=vlan_output)\n>>> vlan_parsed\n[\n {\n 'vlan_id': '1',\n 'name': 'default',\n 'status': 'active',\n 'interfaces': ['Gi0/1']\n },\n {\n 'vlan_id': '10',\n 'name': 'Management',\n 'status': 'active',\n 'interfaces': []\n },\n {\n 'vlan_id': '50',\n 'name': 'VLan50', 'status': 'active',\n 'interfaces': ['Fa0/1', 'Fa0/2', 'Fa0/3', 'Fa0/4', 'Fa0/5', 'Fa0/6', 'Fa0/7', 'Fa0/8']\n }\n]\n>>> \n```\n\n### Define Custom Templates Directory\n\nTo use a custom templates directory set the environmental variable `NTC_TEMPLATES_DIR`.\n\n**Requirements**\n1. `index` file needs to be defined with standard structure. [See](#Index-File)\n2. Each custom template should be defined.\n\nTo manaully set variable:\n```shell\nexport NTC_TEMPLATES_DIR=/path/to/new/location/templates\n```\n\nTo set within your program:\n```python\nimport os\nos.environ[\"NTC_TEMPLATES_DIR\"] = \"/path/to/new/templates/location/templates\"\n```\n\nContributing\n------------\n\nPull requests are welcomed and automatically built and tested through TravisCI.\n\n### New Templates\nTo contribute new templates, each new pull request must include the following:\n\n- TextFSM template\n- Modified version of the **index** file\n- Tests\n * Raw version of text to be parsed\n * YAML file containing the expected parsed dictionary\n\n#### TextFSM Template\n\nTextFSM templates should be placed in the `./templates` directory and should adhere to the following NTC-Templates style.\nThe TextFSM template name should be in the following format:\n\n##### Naming\n\nThe template should be named using: `{{ vendor_os }}_{{ command_with_underscores }}.textfsm`\n> Ex: cisco_ios_show_cdp_neighbors.textfsm\n\nNote: The vendor name must be valid from the [os_choices](https://github.com/networktocode/ntc-templates/blob/master/tests/test_index_order.py#L59) tests, which is primarily based on [Netmiko](https://github.com/ktbyers/netmiko/tree/master/netmiko) list of supported vendors. New vendors added should adhere to **vendor_os**.\n> Ex: vmware_nsx\n\n##### Values\n\nThe capture group names should be in UPPERCASE.\n\nAn example of the proper format is shown below.\n\n```\nValue TIME (\\d+:\\d+:\\d+)\nValue TIMEZONE (\\S+)\nValue DAYWEEK (\\w+)\nValue MONTH (\\d+)\nValue DAY (\\d+)\nValue YEAR (\\d+)\n\nStart\n ^${TIME}\\s+${TIMEZONE}\\s+${DAYWEEK}\\s+${DAY}/${MONTH}/${YEAR} -> Record\n ^. -> Error\n```\n##### States\n\nIf the raw output has a heading, the `Start` state should match on the column headings and then transition to another state that will match the device's output table with the capture groups. This helps ensure the regex patterns for the capture groups are attempting to match the correct information, and allows templates to easily add additional States for tables that have different headings. \nExample:\n\n*Raw Output*\n```\n... omitted\nNetwork Next Hop Metric LocPrf Weight Path\n*> 111.111.111.111/32 112.112.112.112 4294967295 4294967295 65535 1000 1000 1000 i\n```\n\n*Sample Template*\n```\nStart\n# Checking for header\n^\\s*Network\\s+Next(?:\\s+|-)[Hh]op\\s+Metric\\s+LocPrf\\s+Weight\\s+Path\\s*$$ -> BGPTable\n\nBGPTable\n ... omitted\n```\n\nEach **state** should end with `^. -> Error`. This helps to ensure we're accounting for every line within the raw output for the command. This doesn't mean we have to capture all the data as a **Value**, but we do have to account for it. In addition, it is also good to provide an expression to match blank lines, `^\\s*$$`\n\nAn example would be the following raw output:\n```\nNAME: \"3640 chassis\", DESCR: \"3640 chassis\"\nPID: , VID: 0xFF, SN: FF1045C5\n```\n\nThe template would be the following:\n```\nValue NAME (.*)\nValue DESCRIPTION (.*)\n\nStart\n ^NAME:\\s+\"${NAME}\",\\s*DESCR:\\s+\"${DESCRIPTION}\"\n ^PID:\\s*,\\s*VID:\\s*\\S+,\\s*SN:\\s*\\S+\n ^\\s*$$\n ^. -> Error\n```\n\nTaking a look at the example template above, you notice that we're using **\\s*** and **\\s+**. These are the preferred way to match space characters, and should be used over the literal space character. For example, `This\\s+is\\s+preferred\\s*$$` vs `This is not preferred$$`\n\n- **\\s*** accounts for zero or more spaces (use when the output may or may not have a space between characters)\n- **\\s+** accounts for one or more spaces (use when output will have a space, but could have more than one space)\n\n#### Index File\n\nThe Index file binds the templates to the commands being run. Special care has been taken on ordering, as there is potential for issues. e.g. `show ip route` picking up for `show ip router vrf <vrf-name>`. We have used a combination of ordering, as defined:\n\n - OS in alphabetical order\n - Template name in length order (longest to shortest)\n - When length is the same, use alphabetical order of command name\n - Keep space between OS's\n\nExample:\n\n```\nTemplate, Hostname, Platform, Command\n\n# same os, same length, used alphabetical order of command name\narista_eos_show_mlag.textfsm, .*, arista_eos, sh[[ow]] ml[[ag]]\narista_eos_show_vlan.textfsm, .*, arista_eos, sh[[ow]] vl[[an]]\n\n# os in alphabetical order and space between cisco_asa and arista_eos\ncisco_asa_dir.textfsm, .*, cisco_asa, dir\n\n# same os, template name length different and space between cisco_asa and cisco_ios\ncisco_ios_show_capability_feature_routing.textfsm, .*, cisco_ios, sh[[ow]] cap[[ability]] f[[eature]] r[[outing]]\ncisco_ios_show_interface_transceiver.textfsm, .*, cisco_ios, sh[[ow]] int[[erface]] trans[[ceiver]]\ncisco_ios_show_cdp_neighbors_detail.textfsm, .*, cisco_ios, sh[[ow]] c[[dp]] neig[[hbors]] det[[ail]]\n```\n\n#### Tests\nTests will be located in `./tests` with the following hierarchy:\n- `./tests/{{ vendor_os }}/{{ command_name }}/`\n\nThe `{{ command_name }}` directory should include the `.raw` file that includes the raw output of the command to be parsed, and the `.yml` file of the returned structured data.\n```bash\n$ ls tests/cisco_ios/show_clock/\ncisco_ios_show_clock.yml\ncisco_ios_show_clock.raw\n$ \n```\n\n##### Raw version of input text\n\nThe raw text file should contain **only** the output of the CLI command to be parsed. It should **not** contain the CLI command itself.\n\nAn example of the proper format is shown below:\n\n```bash\n$ cat tests/cisco_ios/show_clock/cisco_ios_show_clock.raw\n*18:57:38.347 UTC Mon Oct 19 2015\n$ \n```\n\n##### YAML file containing expected parsed dictionary\n\nThe parsed file should match the data that is returned from the `parse_output` function discussed in the beginning. Dictionary keys should be in lowercase.\n\nThe parsed text file should be placed in a directory in the `./tests` directory with the same name as the template file but replace `.textfsm` file extension with `.yml`. The raw text file and the parsed text file should be in the same directory.\n**ex. ./tests/cisco_ios/show_clock/**\n\nThere are available helpers to create the parsed file in the correct format (See _Development Helper Scripts_ below).\n\nAn example of the proper format is shown below:\n```bash\n$ cat ./tests/cisco_ios/show_clock/cisco_ios_show_clock.yml\n---\nparsed_sample:\n - time: \"18:57:38.347\"\n timezone: \"UTC\"\n dayweek: \"Mon\"\n month: \"Oct\"\n day: \"19\"\n year: \"2015\"\n$ \n```\n\nMultiple `raw` and `parsed` files are supported per directory, and are encouraged, as there are differences depending on version, length, etc. Additional test files and more real life data helps ensure backwards compatibility is maintained as each template is updated and merged into the repo.\n\nAll YAML files must adhere to the YAML standards defined in the `.yamllint` file in the root directory. Yamllint provides thorough documentation of their configuration settings [here](https://yamllint.readthedocs.io/en/stable/rules.html). \n\n##### Development Helper Scripts\n\nA cli utility is provided to assist with properly building the parsed files. This utility depends on some packages listed in the dev install requirements; see _Install and Usage_ for directions on installing the dev requirements. All arguments that can be passed to the script are mutually exclusive (i.e. you can only pass one argument). The file can be made executable with the `chmod +x development_scripts.py` command. The arguments are:\n\n * `-y`: Takes the path to a YAML file and ensures that the file adheres to the .yamllint settings\n * `-yd`: Takes a glob path to a directory or directories that will ensure all files ending in `.yml` adhere to the .yamllint settings\n * `-c`: Takes the path to a `.raw` file, and generates the parsed data and saves the results adjacent to the `.raw` file following the defined standards in .yamllint.\n * `-cd`: Takes a glob path to a directory or directories containing `.raw` files, and creates the appropriate parsed files in the appropriate directory.\n\n The `-y` and `-yd` arguments are designed to allow developers to generate the expected parsed file how they want, and ensure that the formatting adheres to the defined standard for this project.\n\n The `-c` and `-cd` arguments use `ntc_templates.parse.parse_output()` to generate the parsed data; this means that you can use these arguments to auto-generate the test `.yml` file(s) for new templates; just be sure that the template's parsing behavior meets expectations. In order for the data to be parsed, the template must be placed in `ntc_templates/templates/` and the `ntc_templates/templates/index` file must be updated to correctly point to the template file(s).\n\n```bash\n$ ./development_scripts.py -yd tests/cisco_ios/show_mac-address-table\ntests/cisco_ios/show_mac-address-table/cisco_ios_show_mac-address-table2.yml\ntests/cisco_ios/show_mac-address-table/cisco_ios_show_mac-address-table3.yml\ntests/cisco_ios/show_mac-address-table/cisco_ios_show_mac-address-table5.yml\ntests/cisco_ios/show_mac-address-table/cisco_ios_show_mac-address-table4.yml\ntests/cisco_ios/show_mac-address-table/cisco_ios_show_mac-address-table.yml\n$\n$ ls tests/arista_eos/show_version/\narista_eos_show_version.raw\n$\n$ ./development_scripts.py -c tests/arista_eos/show_version/arista_eos_show_version.txt\n$ ls tests/arista_eos/show_version/\narista_eos_show_version.raw arista_eos_show_version.yml\n$\n```\n\n### Updating/Fixing Existing Templates\nWhen either fixing a bug within a template or adding additional **Values** to be captured, additional test files should be added to ensure backwards compatibility and that the new data is being parsed correctly.\n\nTo add additional raw/parsed tests for a command:\n- Navigate to `./tests/{{ vendor_os }}/{{ command_name }}/`\n- Create new `.raw` and `.yml` files within the directory, preferrably with a name identifying why the data is unique:\n * Existing raw: `./tests/cisco_ios/show_version/cisco_ios_show_version.raw`\n * New raw: `./tests/cisco_ios/show_version/cisco_ios_show_version_stack_platforms.raw`\n * Existing parsed: `./tests/cisco_ios/show_version/cisco_ios_show_version.yml`\n * New parsed: `./tests/cisco_ios/show_version/cisco_ios_show_version_stack_platforms.yml`\n\n#### Testing\nYou can test your changes locally within your Git branch before submitting a PR. If you do not have **tox** already installed, you can do that using pip or your systems package manager. Tox should be ran inside the **ntc-templates** root directory. The tox file is configured to run against python3.6,python3.7, and python3.8, if none/some of those python versions are unavailable **tox** will skip them. The tox.ini file can be updated with an available Python version.\n```bash\n$ tox\nGLOB sdist-make: /home/travis/build/networktocode/ntc-templates/setup.py\npy36 create: /home/travis/build/networktocode/ntc-templates/.tox/py36\npy36 inst: /home/travis/build/networktocode/ntc-templates/.tox/.tmp/package/1/ntc_templates-1.6.0.zip\npy36 installed: appdirs==1.4.4,attrs==20.3.0,black==20.8b1,click==7.1.2,dataclasses==0.8,future==0.18.2,importlib-metadata==3.7.0,iniconfig==1.1.1,mypy-extensions==0.4.3,ntc-templates==1.6.0,packaging==20.9,pathspec==0.8.1,pluggy==0.13.1,py==1.10.0,pyparsing==2.4.7,pytest==6.2.2,PyYAML==5.4.1,regex==2020.11.13,ruamel.yaml==0.16.12,ruamel.yaml.clib==0.2.2,six==1.15.0,textfsm==1.1.0,toml==0.10.2,typed-ast==1.4.2,typing-extensions==3.7.4.3,yamllint==1.26.0,zipp==3.4.0\npy36 run-test-pre: PYTHONHASHSEED='4147443973'\npy36 run-test: commands[0] | black ./ --diff --check\nAll done! \u2728 \ud83c\udf70 \u2728\n9 files would be left unchanged.\npy36 run-test: commands[1] | yamllint tests/\npy36 run-test: commands[2] | pytest -vv\n============================= test session starts ==============================\nplatform linux -- Python 3.6.7, pytest-6.2.2, py-1.10.0, pluggy-0.13.1 -- /home/travis/build/networktocode/ntc-templates/.tox/py36/bin/python\ncachedir: .tox/py36/.pytest_cache\nrootdir: /home/travis/build/networktocode/ntc-templates\ncollected 1065 items \n\ntests/test_development_scripts.py::test_ensure_spacing_for_multiline_comment PASSED [ 0%]\ntests/test_development_scripts.py::test_ensure_space_after_octothorpe PASSED [ 0%]\ntests/test_development_scripts.py::test_ensure_space_comments PASSED [ 0%]\ntests/test_development_scripts.py::test_update_yaml_comments PASSED [ 0%]\ntests/test_development_scripts.py::test_transform_file PASSED [ 0%]\ntests/test_testcases_exists.py::test_verify_parsed_and_reference_data_exists[tests/yamaha/show_environment] PASSED [ 99%]\ntests/test_testcases_exists.py::test_verify_parsed_and_reference_data_exists[tests/yamaha/show_ip_route] PASSED [100%]\n\n============================ 1065 passed in 22.59s =============================\npy37 create: /home/travis/build/networktocode/ntc-templates/.tox/py37\nSKIPPED: InterpreterNotFound: python3.7\npy38 create: /home/travis/build/networktocode/ntc-templates/.tox/py38\nSKIPPED: InterpreterNotFound: python3.8\n___________________________________ summary ____________________________________\n py36: commands succeeded\nSKIPPED: py37: InterpreterNotFound: python3.7\nSKIPPED: py38: InterpreterNotFound: python3.8\n congratulations :)\nThe command \"tox\" exited with 0.\n\n\nDone. Your build exited with 0.\n$\n```\n\nQuestions\n---------\n\nFor any questions or comments, please feel free to swing by the [networktocode slack channel](https://networktocode.slack.com).\n\nSign up [here](http://slack.networktocode.com/)\n\nCHANGELOG\n---------\n\nChangelog should be generated using [github_changelog_generator](https://github.com/github-changelog-generator/github-changelog-generator)\n\nFAQ\n---\n\nFrom an outsiders view, some design choices, requirements, and testing procedures can seem arbitrary. The following list of FAQ is intended to \nhelp provide context and better guide users and contributors of ntc-templates.\n\n_Why is there a requirement to use `Error` in every template?_\n\nEnsuring that the textfsm template can account for every line is the only method to ensure that data was not accidentally missed. Take the following example. Initially we account for status to be:\n\n`Value STATUS (up|down)`\n\nGiven the result of:\n```\nInterface Status Protocol Description\nGi0/0/1 admin down down\nGi0/0/2 up up ISP Connection\nGi0/0/3 down down\n```\n\nThe output would miss the G0/0/1 interface, since the `STATUS` of `admin down` not known. If this was a low percentage use case, it can go \nundetected, and result in incorrect information being returned. Instead, by ensuring that we fail fast, an `Error` is raised and hopefully \nGitHub Issue is put in. \n\n_Then why isn't `Error` used in all templates?_\n\nInitially the controls were not as strong, so many templates were put in until issues like the previous became an issue.\n\n_Does the project support requests for additional templates or additional data in an existing template?_\n\nWe are no longer considering additional template requests at this time. The project has existed for over 5 years (initially within ntc-ansible)\nand nearly 200 template at this point any additional requests are essentially edge use cases. Meaning, for five years of usage, no one else \nhas asked for this feature. There is a limited maintainers who primarily use their free time to maintain the project.\n\n_Are you open to adding maintainers to the project?_\n\nYes, we would consider giving a proven member of the project and community maintainer rights. Please inquiry emailing info@networktocode.com.\n\n_I simply want to add my template to the project, I do not want to add all of these tests and controls, can I just do so?_\n\nShort answer no, from an outsiders point of view the contributor requirements may seem overly complex, however features added by engineers \nrarely come back to support them. The burden of support is on the maintainers and a certain level of quality assurance is required for that to \nhappen. That includes updating the index file appropriately and adding proper raw and expected value files.\n\n_Why don't you grab all of the data in the template?_\n\nThere is no intention for ntc-templates to become feature complete, some of the data is less interesting, or can be better understood from \nother commands. This is actually an area where the project chose to be loose, as we do not want to over-burden the contributor. If you feel \nthat the additional data should be added, you are welcome to add the feature, but it would not be considered a bug, and thus not supported by \nthe maintainers of the this project.\n\n_Why does the index order matter?_\n\nThe \"greediness\" of the template match ensures that there longest matches first. For example, if `show ip ospf` was above `show ip ospf database`, the `show ip ospf` template would be used in both cases. The additional steps are because of general programmatic hygiene.\n\n_Will you accept my template if I create it?_\n\nIn most cases, yes. However, there are a few edge cases. For example if requesting to add a `show cdp neighbors` when there is already a `show cdp neighbors details` template created. That is additional complexity added to the project with little value.\n\n_Why was my issue closed?_\n\nThe most likely reasons are:\n\n* Did not follow the Issue creation template.\n* Did not provide the data required to act upon the request.\n* A prolonged time with no response. \n\n_What is meant that this is a parsing project, not a data modeling project?_\n\nThe project intends to parse, meaning post processing is assumed in order to normalize the data. This project does not intend to solve that \nproblem set. This is often noted in keys being different between the same command on multiple OS's. This was not intentional as at first there was not strict enforcement. That being said, there is no intention to retrofit this use case for the above stated reasons. This use case is \nbest handled in post processing.\n\n_I have never submitted a Pull Request before, how do I do so?_\n\nThis is outside the scope of this project, but this [video](https://www.youtube.com/watch?v=rgbCcBNZcdQ) should provide the instructions on \nhow to do so.\n\n_Does this work on windows?_\n\nBased on this [PR](https://github.com/networktocode/ntc-templates/pull/672) it should, however this is not a supported option. We are willing \nto take in qualified Pull Requests to have the feature, but have no intention of actively supporting.\n\n_Can you provide general guidance?_\n\nThis is best handled via real time communication. Feel free to join our slack community (sign up information above) and reach out on the #networktocode channel. Please be aware of timezones, downtimes, and help is performed based on goodwill and timing, and not guaranteed.\n\n### Known Issues\n\n#### Cannot import name clitable from textfsm\n**ntc-templates** depends on **textfsm**, which hasn't published a source distribution to pypi in a while. See https://github.com/google/textfsm/issues/65.\n\nThis means that for users with a build chain that depends on source distributions only (i.e. no wheels), ntc-templates appears to have a bug:\n\n```\nFile \"/usr/local/Cellar/foo/version/libexec/lib/python3.7/site-packages/ntc_templates/parse.py\", line 3, in <module>\n from textfsm import clitable\nImportError: cannot import name 'clitable' from 'textfsm' \n```\n\nWhat's actually happening here is that textfsm provides a source distribution only up to version 0.4.1 (2018-04-09) but the ntc-templates code relies on the interface from version 1.1.0 (2019-07-24) which is only available as a wheel. So the way for users to fix this problem if they encounter it is to install textfsm 1.1.0.\n\n`pip install textfsm==1.1.0`\n\n> This was taken from https://github.com/networktocode/ntc-templates/issues/731\n",
"bugtrack_url": null,
"license": "Apache-2.0",
"summary": "\u7f51\u7edc\u8bbe\u5907TextFSM\u6a21\u677f\uff0c\u5728\u539f\u6709\u7684\u57fa\u7840\u4e0a\u589e\u52a0\u4e2d\u56fd\u4e3b\u6d41\u7f51\u7edc\u8bbe\u5907\u5382\u5546\u7684\u9002\u914d",
"version": "3.5.0",
"split_keywords": [],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "f23dc14dc12005a5670706fa04b94644dcc5263de056342e16f468cf562fd9f7",
"md5": "5f2eb242d19882f8fc33be3768f5566f",
"sha256": "ae1c1cdcb5e5527ab5c6cb7ec63e3e3758ceda7e9c4b6bc72a244acc8eb9e226"
},
"downloads": -1,
"filename": "ntc_templates_elinpf-3.5.0-py3-none-any.whl",
"has_sig": false,
"md5_digest": "5f2eb242d19882f8fc33be3768f5566f",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.7,<4.0",
"size": 395713,
"upload_time": "2023-02-07T08:21:48",
"upload_time_iso_8601": "2023-02-07T08:21:48.463519Z",
"url": "https://files.pythonhosted.org/packages/f2/3d/c14dc12005a5670706fa04b94644dcc5263de056342e16f468cf562fd9f7/ntc_templates_elinpf-3.5.0-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "99725c008d1a5df81c5bbb22fd2251482c69c222e3a9e953836dd6e83ee191c1",
"md5": "8dd4e54879514028c14bfe4c80cb7314",
"sha256": "86aab71b927c269ef0f9ab8df69edfc4cb212e555bfa4a9c87e82e1cbee40cc1"
},
"downloads": -1,
"filename": "ntc_templates_elinpf-3.5.0.tar.gz",
"has_sig": false,
"md5_digest": "8dd4e54879514028c14bfe4c80cb7314",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.7,<4.0",
"size": 212282,
"upload_time": "2023-02-07T08:21:50",
"upload_time_iso_8601": "2023-02-07T08:21:50.785194Z",
"url": "https://files.pythonhosted.org/packages/99/72/5c008d1a5df81c5bbb22fd2251482c69c222e3a9e953836dd6e83ee191c1/ntc_templates_elinpf-3.5.0.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-02-07 08:21:50",
"github": true,
"gitlab": false,
"bitbucket": false,
"github_user": "Elinpf",
"github_project": "ntc-templates",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"lcname": "ntc-templates-elinpf"
}
JSON
