| Name | venvs JSON |
| Version |
2024.5.1
JSON |
| download |
| home_page | |
| Summary | A simpler tool for creating venvs in a central location |
| upload_time | 2024-03-12 11:21:44 |
| maintainer | |
| docs_url | None |
| author | |
| requires_python | >=3.10 |
| license | |
| keywords |
mkvirtualenv
pipx
venv
virtualenv
virtualenvwrapper
|
| VCS |
 |
| bugtrack_url |
|
| requirements |
No requirements were recorded.
|
| Travis-CI |
No Travis.
|
| coveralls test coverage |
No coveralls.
|
=====
venvs
=====
|PyPI| |Pythons| |CI|
``venvs`` is a tool for configuring, in a single file, a set of
virtualenvs, which packages to install into each, and any binaries to
make globally available from within.
Installation
------------
The usual::
$ pip install venvs
Usage
-----
The best way to use ``venvs`` is by creating a file named
``~/.local/share/virtualenvs/virtualenvs.toml``. Here's an example of what goes
in it:
.. code-block::
[virtualenv.development]
install = [
"pudb",
"twisted",
]
link = ["trial"]
[virtualenv.app]
install = ["$DEVELOPMENT/myapp"]
After creating the above, running ``venvs converge`` will create 2
virtualenvs, one called "development" with ``pudb`` and twisted installed
into it and trial linked from within it onto your ``PATH``, and a second
called "app" installing the corresponding directory.
For a more intricate example, have a look at `my own virtualenvs.toml
<https://github.com/Julian/dotfiles/blob/master/.local/share/virtualenvs/virtualenvs.toml>`_.
That's about all you need to know. If you insist on reading further
though, venvs has an older, not-very-recommended mutable interface
which allows you to create virtualenvs in a central location without
tracking them in a config file (or converging them). For that, usage
is similar to ``mkvirtualenv``, although ``venvs`` passes arguments
directly through to ``virtualenv``:
.. code-block:: sh
$ venvs create nameofvenv -- -p pypy
will create a virtual environment in an appropriate platform-specific
data directory, or in the directory specified by ``WORKON_HOME`` for
compatibility with ``virtualenvwrapper``.
Single-Purpose Virtualenvs
--------------------------
A common use case for virtualenvs is for single-purpose installations, e.g.:
"I want to install fabric and give it its own virtualenv so that its
dependencies can be independently upgraded, all while still being able to use
the ``fab`` binary globally".
``venvs`` supports a ``--link`` option for this use case:
.. code-block:: sh
$ venvs create -i fabric --link fab
will create a virtualenv for fabric (in the same normal location), but will
symlink the ``fab`` binary from within the virtualenv into your
``~/.local/bin`` directory.
(You may have heard of `pipsi <https://github.com/mitsuhiko/pipsi>`_ which is a
similar tool for this use case, but with less customization than I would have
liked.)
Temporary Virtualenvs
---------------------
I also find ``mktmpenv`` useful for quick testing. To support its use case,
``venvs`` currently supports a different but similar style of temporary
virtualenv.
Invoking::
$ venv=$(venvs temporary)
in your shell will create (or re-create) a global temporary virtualenv,
and print its ``bin/`` subdirectory (which in this case will be then
stored in the ``venv`` variable). It can subsequently be used by, e.g.::
$ $venv/python
or::
$ $venv/pip ...
et cetera.
You may prefer using::
$ cd $(venvs temporary)
as your temporary venv workflow if you're into that sort of thing instead.
The global virtualenv is cleared each time you invoke ``venvs temporary``.
Unless you care, unlike ``virtualenvwrapper``'s ``mktmpenv``, there's no
need to care about cleaning it up, whenever it matters for the next
time, it will be cleared and overwritten.
``venvs`` may support the more similar "traditional" one-use virtualenv in the
future, but given that it does not activate virtualenvs by default (see below),
the current recommendation for this use case would be to simply use the
``virtualenv`` binary directly.
The 5 Minute Tutorial
---------------------
Besides the ``venvs`` for named-virtualenv creation and ``venvs
temporary`` for temporary-virtualenv creation described above::
$ venvs find name foo
will output (to standard output) the path to a virtualenv with the given name
(see also ``--existing-only``), and::
$ venvs remove foo
will remove it.
There are a number of other slight variants, see the ``--help`` information for
each of the three binaries.
*Real documentation to come (I hope)*
Why don't I use ``virtualenvwrapper``?
--------------------------------------
``virtualenvwrapper`` is great! I've used it for a few years. But I've
slowly settled on a much smaller subset of its functionality that I like
to use. Specifically:
* I don't like activating virtualenvs.
virtualenvs are magical and hacky enough on their own, and piling
activation on top just makes things even more messy for me, especially
when moving around between different projects in a shell. Some people
use ``cd`` tricks to solve this, but I just want simplicity.
* I don't need project support.
I've never attached a project to a virtualenv. I just use a naming
convention, naming the virtualenv with the name of the repo (with simple
coercion), and then using `dynamic directory expansion in my shell
<https://github.com/Julian/dotfiles/blob/4376b05de0f7af9e7ecb2e3596b8830c806c5d71/.config/zsh/.zshrc#L59-L92>`_
to handle association.
Basically, I just want a thing that is managing a central repository of
virtualenvs for me. So that's what ``venvs`` does.
.. |PyPI| image:: https://img.shields.io/pypi/v/venvs.svg
:alt: PyPI version
:target: https://pypi.org/project/venvs/
.. |Pythons| image:: https://img.shields.io/pypi/pyversions/venvs.svg
:alt: Supported Python versions
:target: https://pypi.org/project/venvs/
.. |CI| image:: https://github.com/Julian/venvs/workflows/CI/badge.svg
:alt: Build status
:target: https://github.com/Julian/venvs/actions?query=workflow%3ACI
Raw data
{
"_id": null,
"home_page": "",
"name": "venvs",
"maintainer": "",
"docs_url": null,
"requires_python": ">=3.10",
"maintainer_email": "",
"keywords": "mkvirtualenv,pipx,venv,virtualenv,virtualenvwrapper",
"author": "",
"author_email": "Julian Berman <Julian+venvs@GrayVines.com>",
"download_url": "https://files.pythonhosted.org/packages/1d/8f/795e59d1723af48b481e2a2f075980aca2df994bd0a7cc3e29dcacd123ff/venvs-2024.5.1.tar.gz",
"platform": null,
"description": "=====\nvenvs\n=====\n\n|PyPI| |Pythons| |CI|\n\n``venvs`` is a tool for configuring, in a single file, a set of\nvirtualenvs, which packages to install into each, and any binaries to\nmake globally available from within.\n\n\nInstallation\n------------\n\nThe usual::\n\n $ pip install venvs\n\n\nUsage\n-----\n\nThe best way to use ``venvs`` is by creating a file named\n``~/.local/share/virtualenvs/virtualenvs.toml``. Here's an example of what goes\nin it:\n\n.. code-block::\n\n [virtualenv.development]\n install = [\n \"pudb\",\n \"twisted\",\n ]\n link = [\"trial\"]\n\n [virtualenv.app]\n install = [\"$DEVELOPMENT/myapp\"]\n\nAfter creating the above, running ``venvs converge`` will create 2\nvirtualenvs, one called \"development\" with ``pudb`` and twisted installed\ninto it and trial linked from within it onto your ``PATH``, and a second\ncalled \"app\" installing the corresponding directory.\n\nFor a more intricate example, have a look at `my own virtualenvs.toml\n<https://github.com/Julian/dotfiles/blob/master/.local/share/virtualenvs/virtualenvs.toml>`_.\n\nThat's about all you need to know. If you insist on reading further\nthough, venvs has an older, not-very-recommended mutable interface\nwhich allows you to create virtualenvs in a central location without\ntracking them in a config file (or converging them). For that, usage\nis similar to ``mkvirtualenv``, although ``venvs`` passes arguments\ndirectly through to ``virtualenv``:\n\n.. code-block:: sh\n\n $ venvs create nameofvenv -- -p pypy\n\nwill create a virtual environment in an appropriate platform-specific\ndata directory, or in the directory specified by ``WORKON_HOME`` for\ncompatibility with ``virtualenvwrapper``.\n\n\nSingle-Purpose Virtualenvs\n--------------------------\n\nA common use case for virtualenvs is for single-purpose installations, e.g.:\n\n\"I want to install fabric and give it its own virtualenv so that its\ndependencies can be independently upgraded, all while still being able to use\nthe ``fab`` binary globally\".\n\n``venvs`` supports a ``--link`` option for this use case:\n\n.. code-block:: sh\n\n $ venvs create -i fabric --link fab\n\nwill create a virtualenv for fabric (in the same normal location), but will\nsymlink the ``fab`` binary from within the virtualenv into your\n``~/.local/bin`` directory.\n\n(You may have heard of `pipsi <https://github.com/mitsuhiko/pipsi>`_ which is a\nsimilar tool for this use case, but with less customization than I would have\nliked.)\n\n\nTemporary Virtualenvs\n---------------------\n\nI also find ``mktmpenv`` useful for quick testing. To support its use case,\n``venvs`` currently supports a different but similar style of temporary\nvirtualenv.\n\nInvoking::\n\n $ venv=$(venvs temporary)\n\nin your shell will create (or re-create) a global temporary virtualenv,\nand print its ``bin/`` subdirectory (which in this case will be then\nstored in the ``venv`` variable). It can subsequently be used by, e.g.::\n\n $ $venv/python\n\nor::\n\n $ $venv/pip ...\n\net cetera.\n\nYou may prefer using::\n\n $ cd $(venvs temporary)\n\nas your temporary venv workflow if you're into that sort of thing instead.\n\nThe global virtualenv is cleared each time you invoke ``venvs temporary``.\nUnless you care, unlike ``virtualenvwrapper``'s ``mktmpenv``, there's no\nneed to care about cleaning it up, whenever it matters for the next\ntime, it will be cleared and overwritten.\n\n``venvs`` may support the more similar \"traditional\" one-use virtualenv in the\nfuture, but given that it does not activate virtualenvs by default (see below),\nthe current recommendation for this use case would be to simply use the\n``virtualenv`` binary directly.\n\n\nThe 5 Minute Tutorial\n---------------------\n\nBesides the ``venvs`` for named-virtualenv creation and ``venvs\ntemporary`` for temporary-virtualenv creation described above::\n\n $ venvs find name foo\n\nwill output (to standard output) the path to a virtualenv with the given name\n(see also ``--existing-only``), and::\n\n $ venvs remove foo\n\nwill remove it.\n\nThere are a number of other slight variants, see the ``--help`` information for\neach of the three binaries.\n\n*Real documentation to come (I hope)*\n\n\nWhy don't I use ``virtualenvwrapper``?\n--------------------------------------\n\n``virtualenvwrapper`` is great! I've used it for a few years. But I've\nslowly settled on a much smaller subset of its functionality that I like\nto use. Specifically:\n\n * I don't like activating virtualenvs.\n\n virtualenvs are magical and hacky enough on their own, and piling\n activation on top just makes things even more messy for me, especially\n when moving around between different projects in a shell. Some people\n use ``cd`` tricks to solve this, but I just want simplicity.\n\n * I don't need project support.\n\n I've never attached a project to a virtualenv. I just use a naming\n convention, naming the virtualenv with the name of the repo (with simple\n coercion), and then using `dynamic directory expansion in my shell\n <https://github.com/Julian/dotfiles/blob/4376b05de0f7af9e7ecb2e3596b8830c806c5d71/.config/zsh/.zshrc#L59-L92>`_\n to handle association.\n\nBasically, I just want a thing that is managing a central repository of\nvirtualenvs for me. So that's what ``venvs`` does.\n\n\n.. |PyPI| image:: https://img.shields.io/pypi/v/venvs.svg\n :alt: PyPI version\n :target: https://pypi.org/project/venvs/\n\n.. |Pythons| image:: https://img.shields.io/pypi/pyversions/venvs.svg\n :alt: Supported Python versions\n :target: https://pypi.org/project/venvs/\n\n.. |CI| image:: https://github.com/Julian/venvs/workflows/CI/badge.svg\n :alt: Build status\n :target: https://github.com/Julian/venvs/actions?query=workflow%3ACI\n",
"bugtrack_url": null,
"license": "",
"summary": "A simpler tool for creating venvs in a central location",
"version": "2024.5.1",
"project_urls": {
"Documentation": "https://venvs.readthedocs.io/",
"Funding": "https://github.com/sponsors/Julian",
"Homepage": "https://github.com/Julian/venvs",
"Issues": "https://github.com/Julian/venvs/issues/",
"Source": "https://github.com/python-jsonschema/referencing"
},
"split_keywords": [
"mkvirtualenv",
"pipx",
"venv",
"virtualenv",
"virtualenvwrapper"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "cead189033152300a037cf81fd842f184627b94dec6aed66c238176ef73cfe5f",
"md5": "ba4cf13ea29e6ca5b6a845f341db2055",
"sha256": "6c134e381ba782f0289a9a659998be6b1671ea2a55fbad7f0e9736f06904c160"
},
"downloads": -1,
"filename": "venvs-2024.5.1-py3-none-any.whl",
"has_sig": false,
"md5_digest": "ba4cf13ea29e6ca5b6a845f341db2055",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.10",
"size": 23928,
"upload_time": "2024-03-12T11:21:41",
"upload_time_iso_8601": "2024-03-12T11:21:41.309865Z",
"url": "https://files.pythonhosted.org/packages/ce/ad/189033152300a037cf81fd842f184627b94dec6aed66c238176ef73cfe5f/venvs-2024.5.1-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "1d8f795e59d1723af48b481e2a2f075980aca2df994bd0a7cc3e29dcacd123ff",
"md5": "68444c4084a192f62cc07b9b52f8f8a6",
"sha256": "61bf953d8e0b81dabc7743d42f544aa5a058df70700c4266f871215e9ed2cfcf"
},
"downloads": -1,
"filename": "venvs-2024.5.1.tar.gz",
"has_sig": false,
"md5_digest": "68444c4084a192f62cc07b9b52f8f8a6",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.10",
"size": 23380,
"upload_time": "2024-03-12T11:21:44",
"upload_time_iso_8601": "2024-03-12T11:21:44.824911Z",
"url": "https://files.pythonhosted.org/packages/1d/8f/795e59d1723af48b481e2a2f075980aca2df994bd0a7cc3e29dcacd123ff/venvs-2024.5.1.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-03-12 11:21:44",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "sponsors",
"github_project": "Julian",
"github_not_found": true,
"lcname": "venvs"
}
