automatic import of python-juniper

3 files changed, 611 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index e69de29..38c5fe0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/juniper-0.5.5.tar.gz
diff --git a/python-juniper.spec b/python-juniper.spec
new file mode 100644
index 0000000..d0cb8d0
--- /dev/null
+++ b/python-juniper.spec
@@ -0,0 +1,609 @@
+%global _empty_manifest_terminate_build 0
+Name:		python-juniper
+Version:	0.5.5
+Release:	1
+Summary:	Tool to streamline the build of python lambda functions.
+License:	Apache Software License
+URL:		https://pypi.org/project/juniper/
+Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/82/14/6eee3e4d0413b21808e6446e8824ae490a076675d7ee1ded27caa590abab/juniper-0.5.5.tar.gz
+BuildArch:	noarch
+
+Requires:	python3-click
+Requires:	python3-click-log
+Requires:	python3-PyYAML
+Requires:	python3-Jinja2
+Requires:	python3-docker[ssh]
+Requires:	python3-docker-compose
+
+%description
+|circle| |pypi version| |apache license|
+Juniper is a packaging tool to stream and standardize the creation of a zip
+artifact for a set of AWS Lambda functions.
+The zip artifacts generated include the source code of the dependencies defined
+in a given requirements.txt file as well as any shared libraries the function
+depends on. With the generated artifact, a developer can deploy a lambda function
+either manually, through the awscli or using a cloudformation/sam template.
+Quickstart
+**********
+With Python==3.6 and Docker installed, install juniper:
+    > pip install juniper
+In order to package your lambda functions with juniper, you need to create a
+manifest file.
+    functions:
+      # Name the zip file you want juni to create
+      router:
+        # The dependencies of the router function.
+        requirements: ./src/requirements.txt
+        # Include this file in the generated zip artifact.
+        include:
+        - ./src/lambda_function.py
+The folder structure this manifest refers to looks like:
+    .
+    ├── manifest.yml
+    ├── src
+    │   ├── requirements.txt
+    │   ├── lambda_function.py
+Build it!
+    > juni build
+Juniper creates the following artifact `./dist/router.zip`  🎉
+For a more comprehensive example, please take a look at our `tutorial`_.
+The juni build command will generate the lambda artifact for all the functions and
+layers defined in the manifest file. However, during the development process, it may be
+desired to only build the lambda functions that a developer is actively working on.
+To build only a subset of the resources defined in the manifest use the following
+command:
+    > juni build --skip-clean -f <target_fn_name>
+This command will build all the functions that partially match the given target_fn_name.
+When using a naming convention a developer has the ability to build a subset of
+the lambdas defined in the manifest.
+The skip-clean flag will prevent the previously built artifacts from being deleted
+before the build is executed.
+Python3.7 and Beyond
+********************
+By default juniper uses docker containers to package your lambda functions. Behind
+the scenes, juniper creates a docker-compose file from your manifest. This file is
+used by the `build` command to spawn a build container per function definition.
+Since the AWS Lambda service supports multiple python runtimes, it makes sense for
+juniper to give you the ability to specify a docker image. With the following
+manifest file, you can package the router lambda using a python3.7 image.
+    functions:
+      router:
+        # Use this docker image
+        image: lambci/lambda:build-python3.7
+        requirements: ./src/router/requirements.txt
+        # Include these local modules in the artifact
+        include:
+        - ./src/commonlib/mylib
+        - ./src/router_function/router
+Keep in mind that not every single docker image works, for more information on
+the type of images supported read `juniper and docker`_.
+Lambda Layers
+*************
+AWS Lambda layers is a recent service that gives a developer the ability to
+pre-package a set of dependencies. A lambda function can be built on top of multiple
+layers, either packaged by the developer, by AWS or by a third party.
+To build a layer, the juniper manifest uses a new block:
+  layers:
+    base:
+      requirements: ./src/requirements/base.txt
+    pg:
+      requirements: ./src/requirements/postgres.txt
+With this manifest, running **juni build** creates two layer artifacts: one with the
+name base and another one named pg. Lambda layers are packaged along the lambda
+functions defined in the manifest and the zip files are stored in the artifacts directory.
+The generated artifact includes the dependencies defined in the requirements file
+of the lambda layer.
+Each individual section supports the definition of a custom docker image. With this
+feature, a layer can be built using python3.7 and another one can be built using the
+default python interpreter; python3.6.
+  layers:
+    base:
+      image: lambci/lambda:build-python3.7
+      requirements: ./src/requirements/base.txt
+Juniper builds the artifact for you, you can either use the `layers aws cli`_ to
+upload it to AWS or you can use a SAM template definition. While using a SAM template,
+make sure you use the `AWS::Serverless::LayerVersion` resource.
+To see an example on how to package lambda functions with layers, juniper includes
+an example in the codebase called `ridge`_.
+Configuration
+*************
+To update the default configuration of juniper, can use the the global section
+of the manifest. A sample configuration looks like:
+    global:
+      image: lambci/lambda:build-python3.7
+      output: ./build
+    functions:
+      router:
+        requirements: ./src/router/requirements.txt
+        include:
+        - ./src/router_function/router/lambda_function.py
+Setting a docker image at a global level tells juniper to package every
+lambda function using that image. In this example, the zip artifacts will be stored in
+the ./build folder instead of the ./dist; which is the default.
+Include Binaries
+****************
+Using the lambci build images to create the zip artifacts for a given set of lambda
+functions is sufficient for most use cases. However, there are times when the base container
+does not have all the build libraries necessary to install a python package. In this cases
+running `juni build` fails while trying to pip install the dependencies of the function.
+In addition, once the libraries are installed in the container some packages require a set of
+binaries to work properly at runtime.
+The recommended procedure to install OS libraries and include missing dependencies
+is to use a dockerfile to build a local docker image. The strategy is illustrated as follows:
+* Create a dockerfile using one of the lambci images as a starting point
+* Build a local docker image from the docker file
+* Use the local image in the juniper manifest
+With this startegy, the juniper manifest will look like this:
+    functions:
+      router:
+        image: custom/local_docker_image
+        requirements: ./src/router/requirements.txt
+        include:
+        - ./src/router_function/router/lambda_function.py
+In this case, a developer needs to build the docker image before executing the
+juni build command.
+At this point, the developer can push the docker image to the docker hub and use
+the hosted version instead of the local one. This strategy separates the build of
+a custom image from the build of the artifacts.
+If you need binaries in the final artifact, you can place these files either in the
+**/var/task/lambda_lib/** or the **/var/task/lambda_bin/** depending on your use case.
+Files added to the bin folder are included in the PATH, files added to the lib,
+are included in the LD_LIBRARY_PATH. For more information view `aws layer config`_.
+Juniper is in charge of putting the files in the lambda_bin and lambda_lib in
+the right place when building an artifact.
+A concrete example of the configuration is outlined in the `advanced`_ section
+of our documentation.
+PIP Configuration
+*****************
+To set any pip configuration parameters, create a pip.conf file and add the path
+to the manifest. The **pipconf** setting is only available at a global level and
+it will apply to the packaging of all the functions defined in the manifest.
+  global:
+    pipconf: ./pip.conf
+  functions:
+    sample:
+      requirements: ./requirements.txt
+      include:
+        - ./lambda_function.py
+A sample pip.conf file can be seen bellow, to see the entire list of parameters
+visit the official `pip documentation`_.
+  [global]
+  timeout = 5
+  index-url = https://download.zope.org/ppix
+Features
+********
+This list defines the entire scope of Juniper. Nothing more, nothing else.
+* Minimal manifest file to define packaging
+* Using docker containers as a way to install dependencies and generate the artifacts
+* Ability to tailor the requirements.txt per lambda
+* Create an individual zip artifact for multiple lambda functions
+* Ability to include shared dependencies (python modules relative to the function
+  being packaged)
+* Specify docker image to package lamdba functions using different python runtimes
+* Define pip command line arguments using a pip.conf file
+* Packaging of lambda layers
+Contributing
+************
+For guidance on setting up a development environment and how to make a
+contribution to Juniper, see the `contributing guidelines`_.
+Links
+*****
+* Documentation: https://eabglobal.github.io/juniper/
+* License: `Apache Software License`_
+* Code: https://github.com/eabglobal/juniper
+* Issue tracker: https://github.com/eabglobal/juniper/issues
+* Test status:
+  * Linux, Mac: https://circleci.com/gh/eabglobal/juniper
+
+%package -n python3-juniper
+Summary:	Tool to streamline the build of python lambda functions.
+Provides:	python-juniper
+BuildRequires:	python3-devel
+BuildRequires:	python3-setuptools
+BuildRequires:	python3-pip
+%description -n python3-juniper
+|circle| |pypi version| |apache license|
+Juniper is a packaging tool to stream and standardize the creation of a zip
+artifact for a set of AWS Lambda functions.
+The zip artifacts generated include the source code of the dependencies defined
+in a given requirements.txt file as well as any shared libraries the function
+depends on. With the generated artifact, a developer can deploy a lambda function
+either manually, through the awscli or using a cloudformation/sam template.
+Quickstart
+**********
+With Python==3.6 and Docker installed, install juniper:
+    > pip install juniper
+In order to package your lambda functions with juniper, you need to create a
+manifest file.
+    functions:
+      # Name the zip file you want juni to create
+      router:
+        # The dependencies of the router function.
+        requirements: ./src/requirements.txt
+        # Include this file in the generated zip artifact.
+        include:
+        - ./src/lambda_function.py
+The folder structure this manifest refers to looks like:
+    .
+    ├── manifest.yml
+    ├── src
+    │   ├── requirements.txt
+    │   ├── lambda_function.py
+Build it!
+    > juni build
+Juniper creates the following artifact `./dist/router.zip`  🎉
+For a more comprehensive example, please take a look at our `tutorial`_.
+The juni build command will generate the lambda artifact for all the functions and
+layers defined in the manifest file. However, during the development process, it may be
+desired to only build the lambda functions that a developer is actively working on.
+To build only a subset of the resources defined in the manifest use the following
+command:
+    > juni build --skip-clean -f <target_fn_name>
+This command will build all the functions that partially match the given target_fn_name.
+When using a naming convention a developer has the ability to build a subset of
+the lambdas defined in the manifest.
+The skip-clean flag will prevent the previously built artifacts from being deleted
+before the build is executed.
+Python3.7 and Beyond
+********************
+By default juniper uses docker containers to package your lambda functions. Behind
+the scenes, juniper creates a docker-compose file from your manifest. This file is
+used by the `build` command to spawn a build container per function definition.
+Since the AWS Lambda service supports multiple python runtimes, it makes sense for
+juniper to give you the ability to specify a docker image. With the following
+manifest file, you can package the router lambda using a python3.7 image.
+    functions:
+      router:
+        # Use this docker image
+        image: lambci/lambda:build-python3.7
+        requirements: ./src/router/requirements.txt
+        # Include these local modules in the artifact
+        include:
+        - ./src/commonlib/mylib
+        - ./src/router_function/router
+Keep in mind that not every single docker image works, for more information on
+the type of images supported read `juniper and docker`_.
+Lambda Layers
+*************
+AWS Lambda layers is a recent service that gives a developer the ability to
+pre-package a set of dependencies. A lambda function can be built on top of multiple
+layers, either packaged by the developer, by AWS or by a third party.
+To build a layer, the juniper manifest uses a new block:
+  layers:
+    base:
+      requirements: ./src/requirements/base.txt
+    pg:
+      requirements: ./src/requirements/postgres.txt
+With this manifest, running **juni build** creates two layer artifacts: one with the
+name base and another one named pg. Lambda layers are packaged along the lambda
+functions defined in the manifest and the zip files are stored in the artifacts directory.
+The generated artifact includes the dependencies defined in the requirements file
+of the lambda layer.
+Each individual section supports the definition of a custom docker image. With this
+feature, a layer can be built using python3.7 and another one can be built using the
+default python interpreter; python3.6.
+  layers:
+    base:
+      image: lambci/lambda:build-python3.7
+      requirements: ./src/requirements/base.txt
+Juniper builds the artifact for you, you can either use the `layers aws cli`_ to
+upload it to AWS or you can use a SAM template definition. While using a SAM template,
+make sure you use the `AWS::Serverless::LayerVersion` resource.
+To see an example on how to package lambda functions with layers, juniper includes
+an example in the codebase called `ridge`_.
+Configuration
+*************
+To update the default configuration of juniper, can use the the global section
+of the manifest. A sample configuration looks like:
+    global:
+      image: lambci/lambda:build-python3.7
+      output: ./build
+    functions:
+      router:
+        requirements: ./src/router/requirements.txt
+        include:
+        - ./src/router_function/router/lambda_function.py
+Setting a docker image at a global level tells juniper to package every
+lambda function using that image. In this example, the zip artifacts will be stored in
+the ./build folder instead of the ./dist; which is the default.
+Include Binaries
+****************
+Using the lambci build images to create the zip artifacts for a given set of lambda
+functions is sufficient for most use cases. However, there are times when the base container
+does not have all the build libraries necessary to install a python package. In this cases
+running `juni build` fails while trying to pip install the dependencies of the function.
+In addition, once the libraries are installed in the container some packages require a set of
+binaries to work properly at runtime.
+The recommended procedure to install OS libraries and include missing dependencies
+is to use a dockerfile to build a local docker image. The strategy is illustrated as follows:
+* Create a dockerfile using one of the lambci images as a starting point
+* Build a local docker image from the docker file
+* Use the local image in the juniper manifest
+With this startegy, the juniper manifest will look like this:
+    functions:
+      router:
+        image: custom/local_docker_image
+        requirements: ./src/router/requirements.txt
+        include:
+        - ./src/router_function/router/lambda_function.py
+In this case, a developer needs to build the docker image before executing the
+juni build command.
+At this point, the developer can push the docker image to the docker hub and use
+the hosted version instead of the local one. This strategy separates the build of
+a custom image from the build of the artifacts.
+If you need binaries in the final artifact, you can place these files either in the
+**/var/task/lambda_lib/** or the **/var/task/lambda_bin/** depending on your use case.
+Files added to the bin folder are included in the PATH, files added to the lib,
+are included in the LD_LIBRARY_PATH. For more information view `aws layer config`_.
+Juniper is in charge of putting the files in the lambda_bin and lambda_lib in
+the right place when building an artifact.
+A concrete example of the configuration is outlined in the `advanced`_ section
+of our documentation.
+PIP Configuration
+*****************
+To set any pip configuration parameters, create a pip.conf file and add the path
+to the manifest. The **pipconf** setting is only available at a global level and
+it will apply to the packaging of all the functions defined in the manifest.
+  global:
+    pipconf: ./pip.conf
+  functions:
+    sample:
+      requirements: ./requirements.txt
+      include:
+        - ./lambda_function.py
+A sample pip.conf file can be seen bellow, to see the entire list of parameters
+visit the official `pip documentation`_.
+  [global]
+  timeout = 5
+  index-url = https://download.zope.org/ppix
+Features
+********
+This list defines the entire scope of Juniper. Nothing more, nothing else.
+* Minimal manifest file to define packaging
+* Using docker containers as a way to install dependencies and generate the artifacts
+* Ability to tailor the requirements.txt per lambda
+* Create an individual zip artifact for multiple lambda functions
+* Ability to include shared dependencies (python modules relative to the function
+  being packaged)
+* Specify docker image to package lamdba functions using different python runtimes
+* Define pip command line arguments using a pip.conf file
+* Packaging of lambda layers
+Contributing
+************
+For guidance on setting up a development environment and how to make a
+contribution to Juniper, see the `contributing guidelines`_.
+Links
+*****
+* Documentation: https://eabglobal.github.io/juniper/
+* License: `Apache Software License`_
+* Code: https://github.com/eabglobal/juniper
+* Issue tracker: https://github.com/eabglobal/juniper/issues
+* Test status:
+  * Linux, Mac: https://circleci.com/gh/eabglobal/juniper
+
+%package help
+Summary:	Development documents and examples for juniper
+Provides:	python3-juniper-doc
+%description help
+|circle| |pypi version| |apache license|
+Juniper is a packaging tool to stream and standardize the creation of a zip
+artifact for a set of AWS Lambda functions.
+The zip artifacts generated include the source code of the dependencies defined
+in a given requirements.txt file as well as any shared libraries the function
+depends on. With the generated artifact, a developer can deploy a lambda function
+either manually, through the awscli or using a cloudformation/sam template.
+Quickstart
+**********
+With Python==3.6 and Docker installed, install juniper:
+    > pip install juniper
+In order to package your lambda functions with juniper, you need to create a
+manifest file.
+    functions:
+      # Name the zip file you want juni to create
+      router:
+        # The dependencies of the router function.
+        requirements: ./src/requirements.txt
+        # Include this file in the generated zip artifact.
+        include:
+        - ./src/lambda_function.py
+The folder structure this manifest refers to looks like:
+    .
+    ├── manifest.yml
+    ├── src
+    │   ├── requirements.txt
+    │   ├── lambda_function.py
+Build it!
+    > juni build
+Juniper creates the following artifact `./dist/router.zip`  🎉
+For a more comprehensive example, please take a look at our `tutorial`_.
+The juni build command will generate the lambda artifact for all the functions and
+layers defined in the manifest file. However, during the development process, it may be
+desired to only build the lambda functions that a developer is actively working on.
+To build only a subset of the resources defined in the manifest use the following
+command:
+    > juni build --skip-clean -f <target_fn_name>
+This command will build all the functions that partially match the given target_fn_name.
+When using a naming convention a developer has the ability to build a subset of
+the lambdas defined in the manifest.
+The skip-clean flag will prevent the previously built artifacts from being deleted
+before the build is executed.
+Python3.7 and Beyond
+********************
+By default juniper uses docker containers to package your lambda functions. Behind
+the scenes, juniper creates a docker-compose file from your manifest. This file is
+used by the `build` command to spawn a build container per function definition.
+Since the AWS Lambda service supports multiple python runtimes, it makes sense for
+juniper to give you the ability to specify a docker image. With the following
+manifest file, you can package the router lambda using a python3.7 image.
+    functions:
+      router:
+        # Use this docker image
+        image: lambci/lambda:build-python3.7
+        requirements: ./src/router/requirements.txt
+        # Include these local modules in the artifact
+        include:
+        - ./src/commonlib/mylib
+        - ./src/router_function/router
+Keep in mind that not every single docker image works, for more information on
+the type of images supported read `juniper and docker`_.
+Lambda Layers
+*************
+AWS Lambda layers is a recent service that gives a developer the ability to
+pre-package a set of dependencies. A lambda function can be built on top of multiple
+layers, either packaged by the developer, by AWS or by a third party.
+To build a layer, the juniper manifest uses a new block:
+  layers:
+    base:
+      requirements: ./src/requirements/base.txt
+    pg:
+      requirements: ./src/requirements/postgres.txt
+With this manifest, running **juni build** creates two layer artifacts: one with the
+name base and another one named pg. Lambda layers are packaged along the lambda
+functions defined in the manifest and the zip files are stored in the artifacts directory.
+The generated artifact includes the dependencies defined in the requirements file
+of the lambda layer.
+Each individual section supports the definition of a custom docker image. With this
+feature, a layer can be built using python3.7 and another one can be built using the
+default python interpreter; python3.6.
+  layers:
+    base:
+      image: lambci/lambda:build-python3.7
+      requirements: ./src/requirements/base.txt
+Juniper builds the artifact for you, you can either use the `layers aws cli`_ to
+upload it to AWS or you can use a SAM template definition. While using a SAM template,
+make sure you use the `AWS::Serverless::LayerVersion` resource.
+To see an example on how to package lambda functions with layers, juniper includes
+an example in the codebase called `ridge`_.
+Configuration
+*************
+To update the default configuration of juniper, can use the the global section
+of the manifest. A sample configuration looks like:
+    global:
+      image: lambci/lambda:build-python3.7
+      output: ./build
+    functions:
+      router:
+        requirements: ./src/router/requirements.txt
+        include:
+        - ./src/router_function/router/lambda_function.py
+Setting a docker image at a global level tells juniper to package every
+lambda function using that image. In this example, the zip artifacts will be stored in
+the ./build folder instead of the ./dist; which is the default.
+Include Binaries
+****************
+Using the lambci build images to create the zip artifacts for a given set of lambda
+functions is sufficient for most use cases. However, there are times when the base container
+does not have all the build libraries necessary to install a python package. In this cases
+running `juni build` fails while trying to pip install the dependencies of the function.
+In addition, once the libraries are installed in the container some packages require a set of
+binaries to work properly at runtime.
+The recommended procedure to install OS libraries and include missing dependencies
+is to use a dockerfile to build a local docker image. The strategy is illustrated as follows:
+* Create a dockerfile using one of the lambci images as a starting point
+* Build a local docker image from the docker file
+* Use the local image in the juniper manifest
+With this startegy, the juniper manifest will look like this:
+    functions:
+      router:
+        image: custom/local_docker_image
+        requirements: ./src/router/requirements.txt
+        include:
+        - ./src/router_function/router/lambda_function.py
+In this case, a developer needs to build the docker image before executing the
+juni build command.
+At this point, the developer can push the docker image to the docker hub and use
+the hosted version instead of the local one. This strategy separates the build of
+a custom image from the build of the artifacts.
+If you need binaries in the final artifact, you can place these files either in the
+**/var/task/lambda_lib/** or the **/var/task/lambda_bin/** depending on your use case.
+Files added to the bin folder are included in the PATH, files added to the lib,
+are included in the LD_LIBRARY_PATH. For more information view `aws layer config`_.
+Juniper is in charge of putting the files in the lambda_bin and lambda_lib in
+the right place when building an artifact.
+A concrete example of the configuration is outlined in the `advanced`_ section
+of our documentation.
+PIP Configuration
+*****************
+To set any pip configuration parameters, create a pip.conf file and add the path
+to the manifest. The **pipconf** setting is only available at a global level and
+it will apply to the packaging of all the functions defined in the manifest.
+  global:
+    pipconf: ./pip.conf
+  functions:
+    sample:
+      requirements: ./requirements.txt
+      include:
+        - ./lambda_function.py
+A sample pip.conf file can be seen bellow, to see the entire list of parameters
+visit the official `pip documentation`_.
+  [global]
+  timeout = 5
+  index-url = https://download.zope.org/ppix
+Features
+********
+This list defines the entire scope of Juniper. Nothing more, nothing else.
+* Minimal manifest file to define packaging
+* Using docker containers as a way to install dependencies and generate the artifacts
+* Ability to tailor the requirements.txt per lambda
+* Create an individual zip artifact for multiple lambda functions
+* Ability to include shared dependencies (python modules relative to the function
+  being packaged)
+* Specify docker image to package lamdba functions using different python runtimes
+* Define pip command line arguments using a pip.conf file
+* Packaging of lambda layers
+Contributing
+************
+For guidance on setting up a development environment and how to make a
+contribution to Juniper, see the `contributing guidelines`_.
+Links
+*****
+* Documentation: https://eabglobal.github.io/juniper/
+* License: `Apache Software License`_
+* Code: https://github.com/eabglobal/juniper
+* Issue tracker: https://github.com/eabglobal/juniper/issues
+* Test status:
+  * Linux, Mac: https://circleci.com/gh/eabglobal/juniper
+
+%prep
+%autosetup -n juniper-0.5.5
+
+%build
+%py3_build
+
+%install
+%py3_install
+install -d -m755 %{buildroot}/%{_pkgdocdir}
+if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi
+if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi
+if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi
+if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi
+pushd %{buildroot}
+if [ -d usr/lib ]; then
+	find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst
+fi
+if [ -d usr/lib64 ]; then
+	find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst
+fi
+if [ -d usr/bin ]; then
+	find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst
+fi
+if [ -d usr/sbin ]; then
+	find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst
+fi
+touch doclist.lst
+if [ -d usr/share/man ]; then
+	find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst
+fi
+popd
+mv %{buildroot}/filelist.lst .
+mv %{buildroot}/doclist.lst .
+
+%files -n python3-juniper -f filelist.lst
+%dir %{python3_sitelib}/*
+
+%files help -f doclist.lst
+%{_docdir}/*
+
+%changelog
+* Wed May 31 2023 Python_Bot <Python_Bot@openeuler.org> - 0.5.5-1
+- Package Spec generated
diff --git a/sources b/sources
new file mode 100644
index 0000000..0ea1240
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+eaeb1591586677bc17825fe3fd5b7cb1  juniper-0.5.5.tar.gz