<p>One could consider to package the scripts. Depending on the distribution, e.g. ubuntu, windows, centos one could create a ppa, nuget or rpm respectively. Once a newer version is installed, the package manager will remove the previous version automatically.</p>

<p>As yum or zypper could be used to install packages on OpenSuse one could consider to create an rpm by using either spec files or using <a href="https://github.com/jordansissel/fpm" rel="nofollow noreferrer">fpm</a>.</p>

CC BY-SA 3.0
2017-08-10T06:32:35.840Z
2017-08-10T06:57:15.393Z
2017-08-10T06:57:15.393Z
030
<p><a href="https://github.com/melezhik/sparrow" rel="nofollow noreferrer">Sparrow</a> makes scripts deployment and distribution simple and super flexible. It is kinda language agnostic system, meaning you can write scripts on <em>many</em> languages, Python is included. There is a <a href="https://dev.to/melezhik/distributing-portable-scripts-with-sparrow-8f4" rel="nofollow noreferrer">nice introduction</a> on script distribution with Sparrow.</p>

<p>The only hurdle with your case you will have to adjust existed scripts so that they could be packaged, it's pretty straightforward process though. </p>

CC BY-SA 4.0
2018-11-20T21:58:25.507Z
2018-11-20T21:58:25.507Z
Alexey Melezhik
<p>I have a lot of python scripts which I release to a python virtual environment on a remote machine. The virtual environment is rarely updated. The scripts are pulled from a git repository and a makefile is used to deploy them into the virtual environment directory.</p>

<p>My question: is there a more normal way to deploy the scripts?</p>

<p>I would like a process that at least remembers which files were deployed for cleanup upon the next release. I've read a bit on pip packaging, but I'm not sure if it fits our setup. The scripts need to be in a common location where they can be called by other applications. The OS is SUSE Linux.</p>

CC BY-SA 3.0
2017-08-10T06:20:12.350Z
Could you add the distribution, e.g. ubuntu, centos as a tag?
030
CC BY-SA 3.0
2017-08-10T06:50:05.937Z
The distro is SUSE Linux
Dawn555
<continuous-deployment><release-management><python>
Recommendations about release convention or standard for Python scripts?
Dawn555
# Recommendations about release convention or standard for Python scripts?

(Asked by: username_0 on 2017-08-10)

I have a lot of python scripts which I release to a python virtual environment on a remote machine. The virtual environment is rarely updated. The scripts are pulled from a git repository and a makefile is used to deploy them into the virtual environment directory.

My question: is there a more normal way to deploy the scripts?

I would like a process that at least remembers which files were deployed for cleanup upon the next release. I've read a bit on pip packaging, but I'm not sure if it fits our setup. The scripts need to be in a common location where they can be called by other applications. The OS is SUSE Linux.

**Tags:** continuous-deployment, release-management, python

> **Comments:**
> **username_1**: Could you add the distribution, e.g. ubuntu, centos as a tag?  
> **username_0**: The distro is SUSE Linux  

---

## 2 answers

### Answer by username_1 on 2017-08-10. Score: 4

One could consider to package the scripts. Depending on the distribution, e.g. ubuntu, windows, centos one could create a ppa, nuget or rpm respectively. Once a newer version is installed, the package manager will remove the previous version automatically.

As yum or zypper could be used to install packages on OpenSuse one could consider to create an rpm by using either spec files or using [fpm](https://github.com/jordansissel/fpm).


---

### Answer by username_2 on 2018-11-20. Score: 0

[Sparrow](https://github.com/melezhik/sparrow) makes scripts deployment and distribution simple and super flexible. It is kinda language agnostic system, meaning you can write scripts on *many* languages, Python is included. There is a [nice introduction](https://dev.to/melezhik/distributing-portable-scripts-with-sparrow-8f4) on script distribution with Sparrow.

The only hurdle with your case you will have to adjust existed scripts so that they could be packaged, it's pretty straightforward process though.


---

