Saravanan666/pypi-org huggingface dataset:
Package: virtualenv-activator
The default activate script for Python’svirtualenvhad some
problems that bugged me:It doesn’t work withvirtualenv--relocatableso you can’t move or rename your virtual
environment directory.I wanted an easy way to modify the shell environment (manually or automatically) inside a virtual
environment and have it restored when I deactivate it.Some other stuff I can’t remember.This package provides a replacement activate script that automatically…makes your virtual environment relocatable and keeps it that way even when you install new stuff
(caveat: don’t move or rename your virtual environment while it’s activated).sources an optionaletc/environment.shfile where you can modify your shell environment every
time your virtual environment is activated.restores your shell environment upon deactivation to the state it was in before you activated.ExampleCreate a new virtual environment, installvirtualenv-activatorinside it, and then activate it
using theetc/activate.shscript.$ cd /path/to/my_code
$ virtualenv venv
$ venv/bin/pip install virtualenv-activator
$ . venv/etc/activate.sh
(my_code) $Deactivate as normal…(my_code) $ deactivateWell, it’s not as normal as it looks. There’s some magic happening under the hood. Try setting an
environment variable in theetc/environment.shfile (this file doesn’t exist by default) in your
virtual environment, but also set the same variable to a different value while you’re outside the
virtual environment, and then watch what happens the variable as you activate and deactivate the
environment.$ echo 'export MY_VAR="inside venv"' > venv/etc/environment.sh
$ export MY_VAR="outside venv"
$ echo $MY_VAR
outside venv
$ . venv/etc/activate.sh
(my_code) $ echo $MY_VAR
inside venv
(my_code) $ export MY_VAR="manually set"
(my_code) $ echo $MY_VAR
manually set
(my_code) $ deactivate
$ echo $MY_VAR
outside venv
$ . venv/etc/activate.sh
(my_code) $ echo $MY_VAR
inside venvBasically, you can put pretty much anything bash related (variables, aliases, functions, etc.) in
theetc/environment.shscript and it will only exist when your virtual environment is activated.NOTE:You may have noticed in the example above that the parent directory’s basename was used in
my prompt instead of the basename of the virtual environment directory itself. It does this when you
name your virtual environment something generic likevenv, in which case it wouldn’t really be
very informative to have that in your prompt. It uses this regular expression to decide if the name
is “generic”:^\.?v(irtual)?env$Simple ModeSimple mode is enabled via theVIRTUALENV_ACTIVATOR_SIMPLEenvironment variable. When this
variable is set, the activator doesn’t try to restore your environment to its previous state. It
doesn’t even provide adeactivatefunction. This is sometimes more desirable when running a
daemon for instance. Here’s an example of a bash script you might write to wrap a daemon written in
Python so that the virtual environment is automatically activated for the daemon:#!/bin/bash
export VIRTUALENV_ACTIVATOR_SIMPLE=1
. /path/to/venv/etc/activate.sh
my_daemon "$@"
Package: virtualenv-asdf
virtualenv-asdfAvirtualenvPython discovery plugin usingasdfInstallationpipinstallvirtualenv-asdfUsageThe Python discovery mechanism can be specified by:the CLI option--discovery:virtualenv--discoveryasdf-p3.10testenvthe environment variableVIRTUALENV_DISCOVERY:exportVIRTUALENV_DISCOVERY=asdf
virtualenv-p3.10testenvtheconfigoptiondiscovery:[virtualenv]discovery=asdfvirtualenvasdf-p3.10testenvThe Python version can be expressed using either 2 or 3 version segments:-p 3.9-p 3.9.3In the former case, the latest version found will be used.LimitationsOnly CPython is supported at the moment.NOTE: this package derived fromvirtualenv-pyenvby un.def
Package: virtualenv-bin
Tools to install into a python virtualenv to make life easier.
If you install virtualenv-bin into a virtualenv, you will get two useful
programs.venvbinIf you symlink to this program where it sits in a virtualenv and name the
symlink for any program in the bin folder, executing the symlink will
activate the virtualenv and then run the program, passing through all args
and exit codes.exampleI want to install and use httpie, but I don’t want any of it’s dependencies
interfering with my broader environment.  Note: for this example, I use
/opt/virtualenvs for all virtualenvs.$mkvirtualenvhttpie$source/opt/virtualenvs/httpie/bin/activate$pipinstall--upgradehttpie$pipinstallvirtualenv-bin$cd~/bin$ln-s/opt/virtualenvs/httpie/bin/venvbinhttp$~/bin/httpexample.orgHTTP/1.0302FoundConnection:Keep-AliveContent-Length:0Location:http://www.iana.org/domains/example/Server:BigIPvenvsymlinkRunning this from a bin directory will automatically symlink all bins (except
the ones that are in all virtualenvs as well as any bins from virtualenv-bin)
from that virtualenv into your bin folder using venvbinexampleI want to install and use httpie, but I don’t want any of it’s dependencies
interfering with my broader environment.  Note: for this example, I use
/opt/virtualenvs for all virtualenvs.$mkvirtualenvhttpie$source/opt/virtualenvs/httpie/bin/activate$pipinstall--upgradehttpie$pipinstallvirtualenv-bin$cd~/bin$/opt/virtualenvs/httpie/bin/venvsymlinks$~/bin/httpexample.orgHTTP/1.0302FoundConnection:Keep-AliveContent-Length:0Location:http://www.iana.org/domains/example/Server:BigIPvenvlaunchRunning this lets you execute a program that is inside a virtualenv directlyexampleHere we are going to run http from directly inside the virtualenv.$mkvirtualenvhttpie$source/opt/virtualenvs/httpie/bin/activate$pipinstall--upgradehttpie$pipinstallvirtualenv-bin$cd~/bin$/opt/virtualenvs/httpie/bin/venvsymlinks$~/bin/http--help$/opt/virtualenvs/httpie/bin/venvlaunchhttpexample.orgHTTP/1.0302FoundConnection:Keep-AliveContent-Length:0Location:http://www.iana.org/domains/example/Server:BigIPinstallationYou can install virtualenv-bin using pip.  There’s no point to installing this
anywhere other then into a virtualenv you want to use it with.$pipinstallvirtualenv-bin
Package: virtualenv-bootstrap
Welcome tovirtualenv_bootstrapDocumentation在自动化运维领域, 用 Python 来代替 Bash 来写 shell script 能够极大的提升代码的可维护性. 仅使用标准库就能做到大部分的事情了. 在少数情况下, 我们依然需要安装一些第三方库来完成一些业务逻辑. 通常情况下, 我们需要手动安装依赖, 还有可能需要用到 virtualenv 以避免污染 global Python, 然后才能运行脚本. 这个库的意义是简化这一步骤, 通过自动创建 virtualenv 和安装依赖的方式, 使得你用任何 Python 解释器都能运行你的 shell script.Installvirtualenv_bootstrapis released on PyPI, so all you need is to:$pipinstallvirtualenv-bootstrapTo upgrade to latest version:$pipinstall--upgradevirtualenv-bootstrap
Package: virtualenv-clone
virtualenv cloning script.A script for cloning a non-relocatable virtualenv.Virtualenv provides a way to make virtualenv's relocatable which could then be
copied as we wanted. However making a virtualenv relocatable this way breaks
the no-site-packages isolation of the virtualenv as well as other aspects that
come with relative paths and/usr/bin/envshebangs that may be undesirable.Also, the .pth and .egg-link rewriting doesn't seem to work as intended. This
attempts to overcome these issues and provide a way to easily clone an
existing virtualenv.It performs the following:copiessys.argv[1]dir tosys.argv[2]updates the hardcodedVIRTUAL_ENVvariable in the activate script to the
new repo location. (--relocatabledoesn't touch this)updates the shebangs of the various scripts in bin to the new Python if
they pointed to the old Python. (version numbering is retained.)it can also change/usr/bin/env pythonshebangs to be absolute too,
though this functionality is not exposed at present.checkssys.pathof the cloned virtualenv and if any of the paths are from
the old environment it finds any.pthor.egglink files within sys.path
located in the new environment and makes sure any absolute paths to the
old environment are updated to the new environment.finally it double checkssys.pathagain and will fail if there are still
paths from the old environment present.NOTE: This script requires Python 2.7 or 3.4+
Package: virtualenvcontext
Example>>> from virtualenvcontext import VirtualenvContext>>> try:
>>>     import kitchen
>>> except ImportError as e:
>>>     print "kitchen is definitely not installed in system-python">>> with VirtaulenvContext("my-venv"):
>>>     import kitchen
>>>     print "But it *is* installed in my virtualenv">>> try:
>>>     import kitchen
>>> except ImportError as e:
>>>     print "But once I exit that block, I lose my powers again..."Caveat:It expects that you’re usingvirtualenvwrapperbut
you should be anyways.Get this project:Source:http://github.com/ralphbean/virtualenvcontext/pypi:http://pypi.python.org/pypi/virtualenvcontext/
Package: virtualenv-make-relocatable
virtualenv-make-relocatablesimple tool to make scripts provided by virtualenv relocatableBackgroundHistorically virtualenv supported option--relocatableto rewrite shibangs for scripts installed in it.
It's very useful option if you plan to create docker image from your virtualenv directory.
Unfortunately since version20.0virtualenv removed this option.This project provides tool for performing removed functionalityHow to usejust runvirtualenv-make-relocatable <VENV-DIRECTORY>
Package: virtualenv-multiver
virtualenv-multiveris a wrapper aroundvirtualenv, the standard tool for
creating isolated Python environments. It’s built to allow multiple versions
of Python to be usable within a single environment. This is really handy when
you’re doing development and testing across a range of Python versions, and
you don’t want to have to juggle your active environment for every version.InstallationSimple:pip install virtualenv-multiverUsageAlso simple. To create a new virtual environment, just provide the path to
that environment and the versions you want installed. For example:virtualenv-multiver ~/venvs/my-project 2.7 3.6 3.7 3.8Or:virtualenv-multiver ~/venvs/my-project pypy pypy3The resulting virtual environment will include all those versions of Python
without any additional configuration.FAQHow does this work?virtualenv-multiverruns through the list of Python versions provided and
calls out tovirtualenvfor each versionAfter eachvirtualenvcall, it fixes up the tree a bit. This involves:Ensuring symlinks point to the right place (python2points to the
latestpython2.*specified, for instance)Patching any installed scripts (such aspip3.8) and making sure it
points to the correct, versioned interpreterMoves and patches some binaries and configuration files around to avoid
collision issues.Once done, it sets the top-level symlinks forpython2,python3,pip2,pip3, etc. (any that specify a major version) to point to the
latest version in that series.It then sets the generic, version-less ones (python,pip, etc.) to
point to the Python 2 versions (if Python 2 is installed), or Python 3 (if
not). This helps ensure compatibility with scripts that expectpythonto
mean “Python 2”.Are all versions of CPython supported?Yes. Pretty much. It depends on whether virtualenv itself will support the
version.Is PyPY supported?Yes. Sorta.PyPy doesn’t cleanly install alongside CPython in a virtual environment, due
to CPython and PyPy claiming some of the same files and directories. We only
allow PyPy to install independently or alongside another PyPy.You may have issues even with multiple PyPy installations. They’ll install and
run, but will share the samesite-packagesdirectory, which is beyond our
control for the moment.If this isn’t a problem for you, go for it. Otherwise, you may want to stick
to a standardvirtualenvcall for those.How do I report a bug?You can file an issue on the GitHub issue tracker.Who uses this?We usevirtualenv-multiveratBeanbagfor ourReview BoardandRBCommonsproducts.If you use this, let us know and we’ll add you to a list here!What else do you build?Lots of things. Check out some of our otheropen source projects.
Package: virtualenv-rewrite
This is based on therewritebranch of virtualenv:https://github.com/pypa/virtualenv/tree/rewriteWhat pythons are currently supported in this fork:Python 2.6PyPyPyPy3 (on Windows it doesn’t really work causepip is broken on the 2.4.0 release)Python 2.6Python 2.7Python 3.2 (tested but unsupported, check test results for exact situation)Python 3.3Python 3.4What’s currently tested (on Windowsand Linux):creationrecreation--system-site-packages(incl. ordering of sites).pthsupportbin scriptstox integrationC extensions compile properly insideDebian-flavored linuxes are also supported (with their messy patches on site.py/distutils/sysconfig).What’s missing:No symlinks or hardlinks, just dumb copies.Relocation support (it wasn’t really supported in legacy virtualenv anyway).You tell me …Try itOption 1: release from alternate indexThe alternate index:https://anaconda.org/ionelmc/virtualenvTo install:pip install -i https://pypi.anaconda.org/ionelmc/simple virtualenvOption 2: development versionpip install --ignore-installed https://github.com/ionelmc/virtualenv/archive/develop.zipOption 3: release with different nameThere’s an alternative package onPyPI:virtualenv-rewrite:pip install virtualenv-rewriteNoteIf you install it over the legacy virtualenv you may have issues. To keep things simple you should uninstall it
before, eg:pip uninstall virtualenv
pip install virtualenv-rewriteDocsFor the old documentation, seehttps://virtualenv.pypa.io/Changelog14.1.0 (2015-10-02)Update bundled setuptools to18.3.2.Update bundled wheel to0.26.0.Fixed issues with case normalization on Windows (some paths weren’t properly case-normalized).14.0.0 (2015-09-15)Initial PyPI release.
Package: virtualenvrunner
READMEDocumentationDocumentation for virtualenvrunner can be found fromRead The Docs.run_in_virtualenv toolThis distribution containsrun_in_virtualenvtool and programmatic usage of
the tool. The tool is for running shell commands in virtualenv.The tool is similar toallvirtualenvinvirtualenvwrapperortoxbut
restricted to the command line run only.Moreover, the library provides Python function for running generic runner
function in virtualenv.Development practicesThe development and the testing follows the Common Robot Libraries development
practices defined incrl-devutils.
Package: virtualenv-seedhelper
virtualenv-seedhelperA virtualenv seeder to seed wheels from a folderQuick startInstall in system python environmentpython3 -m pip install virtualenv-seedhelperConfigure virtualenv to always use seedhelperseedhelper configNote that this overwritesvirtualenv.iniif it already exists.Add wheels to SEEDHELPER_WHEELS_DIR one at a time by URLseedhelper download https://files.pythonhosted.org/packages/f1/13/63c0a02c44024ee16f664e0b36eefeb22d54e93531630bd99e237986f534/cowsay-6.1-py3-none-any.whlCreate a new virtualenvpython3 -m virtualenv venvVerify that the new virtualenv has the wheels installed in it$ venv/bin/pip list
Package    Version
---------- -------
cowsay     6.1
pip        23.2.1
setuptools 68.2.2
wheel      0.41.2What if we want to seed a package with dependencies?Instead of looking up and downloading wheel URLs one by one, we can useseedhelper requireto download the wheels for all the dependencies of a
requirement, placing all of their wheels in theSEEDHELPER_WHEELS_DIRso that
they all get seeded into newly-created virtualenvs.seedhelper require requests==2.31.0After this, we can make a new virtualenvpython3 -m virtualenv venvand verify that it has all the dependencies installed$ venv/bin/pip list
Package            Version
------------------ ---------
certifi            2023.7.22
charset-normalizer 3.3.0
idna               3.4
pip                23.2.1
requests           2.31.0
setuptools         68.2.2
urllib3            2.0.7
wheel              0.41.2and we can import the package in the venvvenv/bin/python -c 'import requests'ConfigSEEDHELPER_WHEELS_DIRThis is where seedhelper will download wheels to. It defaults to~/Library/Application Support/virtualenv/seedhelper_wheels(or the
corresponding location on your specific platform as provided byplatformdirs.user_config_dir()). You can override it by setting an
environment variable calledSEEDHELPER_WHEELS_DIR.VIRTUALENV_CONFIG_FILEThis is where virtualenv (and seedhelper) will look forvirtualenv.ini. It
defaults to~/Library/Application Support/virtualenv/virtualenv.ini(or the
corresponding location on your specific platform as provided byplatformdirs.user_config_dir()). You can override it by setting an
environment variable calledVIRTUALENV_CONFIG_FILE.MotivationThe goal is to make it possible to include a set of wheels in every virtualenv
created. This is especially useful when the system-wide pip configuration
assumes that certain packages, such as keyring backends needed to interact with
a private package index, will always be available before pip runs. Without a
seeder, you cannot use pip to install the keyring because pip itself needs the
keyring to be already installed in order to function at all.
Package: virtualenv-tauthon
Aboutvirtualenv-tauthonis an externalVirtualenvplugin that addsTauthonsupport,
as describedhere.With this module and Tauthon installed, you can create a Tauthon-based virtual environment like this:virtualenv-ptauthon2.8my_venvInstallationThis package isavailable on PyPi:pipinstallvirtualenv-tauthonLicenseMITCreditsauthor: Ștefan Talpalarustefantalpalaru@yahoo.comhomepage:https://github.com/stefantalpalaru/virtualenv-tauthon
Package: virtualenv-tools
– virtualenv-toolsThis repository contains scripts we’re using at Fireteam for our
deployment of Python code.  We’re using them in combination with
salt to build code on one server on a self contained virtualenv
and then move that over to the destination servers to run.Why not virtualenv –relocatable?For starters: because it does not work.  relocatable is very
limited in what it does and it works at runtime instead of
making the whole thing actually move to the new location.  We
ran into a ton of issues with it and it is currently in the
process of being phased out.Why would I want to use it?The main reason you want to use this is for build caching.  You
have one folder where one virtualenv exists, you install the
latest version of your codebase and all extensions in there, then
you can make the virtualenv relocate to a target location, put it
into a tarball, distribute it to all servers and done!Example flow:First time: create the build cache$ mkdir /tmp/build-cache
$ virtualenv –distribute /tmp/build-cacheNow every time you build:$ . /tmp/build-cache/bin/activate
$ pip install YourApplicationBuild done, package up and copy to whatever location you want to have
it.Once unpacked on the target server, use the virtualenv tools to
update the paths and make the virtualenv magically work in the new
location.  For instance we deploy things to a path with the
hash of the commit in:$ virtualenv-tools –update-path /srv/your-application/<hash>To also update the Python executable in the virtualenv to the
system one you can reinitialize it in one go:$ virtualenv-tools –reinitialize /srv/your-application/<hash>Compile once, deploy whereever.  Virtualenvs are completely self
contained.  In order to switch the current version all you need to
do is to relink the builds.
Package: virtualenv-tools3
virtualenv-tools3virtualenv-tools3 is a fork ofthe original
virtualenv-tools(now
unmaintained) which adds support for Python 3, among other things. Full patch
details are below.yelp patchesyelp4Add python3 supportDrop python2.6 support100% test coverageRemoves$VENV/localinstead of fixing up symlinksRemoved--reinitialize, instead runvirtualenv $VENV -p $PYTHONRewrite .pth files to relative pathsyelp3default output much more concise, added a --verbose optionimproved fault tolerance, in the case of:corrupt pyc filesbroken symlinksunexpected directoriesno-changes-needed is a success case (idempotency exits 0)yelp1--update now works more generally and reliably (e.g. virtualenv --python=python2.7)virtualenv-toolsThis repository contains scripts we're using at Fireteam for our
deployment of Python code.  We're using them in combination with
salt to build code on one server on a self contained virtualenv
and then move that over to the destination servers to run.Why not virtualenv --relocatable?For starters: because it does not work.  relocatable is very
limited in what it does and it works at runtime instead of
making the whole thing actually move to the new location.  We
ran into a ton of issues with it and it is currently in the
process of being phased out.Why would I want to use it?The main reason you want to use this is for build caching.  You
have one folder where one virtualenv exists, you install the
latest version of your codebase and all extensions in there, then
you can make the virtualenv relocate to a target location, put it
into a tarball, distribute it to all servers and done!Example flow:First time: create the build cache$ mkdir /tmp/build-cache
$ virtualenv --distribute /tmp/build-cacheNow every time you build:$ . /tmp/build-cache/bin/activate
$ pip install YourApplicationBuild done, package up and copy to whatever location you want to have it.Once unpacked on the target server, use the virtualenv tools to
update the paths and make the virtualenv magically work in the new
location.  For instance we deploy things to a path with the
hash of the commit in:$ virtualenv-tools --update-path /srv/your-application/<hash>Compile once, deploy whereever.  Virtualenvs are completely self
contained.  In order to switch the current version all you need to
do is to relink the builds.
Package: virtualenv-tools-enhanced
virtualenv-tools-enhancedvirtualenv-tools-enhanced is a fork ofvirtualenv-tools3.virtualenv-tools-enhancedThis repository contains scripts I am using for my portable environment
used to develop with VSCodium.
As the environmnet is portable across different plateforms and computers,
I need a way to get Python and virtualenv working everywhere.Why not virtualenv --relocatable?For starters: because it does not work. Relocatable is very
limited in what it does and it works at runtime instead of
making the whole thing actually move to the new location.  We
ran into a ton of issues with it and it is currently in the
process of being phased out.Why not virtualenv-tools3?Because of some lack of Windows support.
Because...Why would I want to use it?The main reason you want to use this is simplification.
No more long options, some more 'usefull' features.Help :usage: virtualenv_tools.py [-h] [-m] [-u UPDATE_PATH] [-b BASE_PYTHON_DIR] [-f] [-c] [-v] [path]

Update paths in a virtualenv before/after moving it or a Python installation after moving it.

positional arguments:
  path                  Virtualenv folder, default to "."
                        Executable for main update.

optional arguments:
  -h, --help            show this help message and exit
  -m, --main            Update Python home after moving it.Portable Python is bad, not recommended and not supported.But why not?Windows only
  -u UPDATE_PATH, --update-path UPDATE_PATH
                        Update the path for all required executables and helper files that are supported to the new python prefix.
                        If omitted, path argument will be used.If a virtualenv name is given and "WORKON_HOME" is set, it will updatethis virtualenv otherwise fallback to path argument.
  -b BASE_PYTHON_DIR, --base-python-dir BASE_PYTHON_DIR
                        On Windows, a directory pointing to a valid Python installation.
                        On *nux, a valid Python executable.
                        The virtualenv will load standard libraries from here.This is needed to update pyvenv.cfg with a non default installation.If omitted, the default python will be used.
  -f, --force           Continue processing even if the original path is the same as the updated path.
  -c, --clean           Clean .pyc and .pyo files which are not the same version of the Python in the virtualenv or the main installation.
  -v, --verbose         Show a listing of changes

To be able to give a virtualenv name, WORKON_HOME variable must be set
Before moving : virtualenv_tools.py -u new/path/of/venv old/path/of/venv
Before moving : virtualenv_tools.py -u new/path/of/venv old_venv
After moving and in the virtualenv : virtualenv_tools.py
After moving : virtualenv_tools.py new_venv
After moving : virtualenv_tools.py new/path/of/venv.

For main installation, python as executable
virtualenv_tools.py -m python