virtualenv-sh

virtualenv-sh er en erstatning for den ærverdige virtualenvwrapper & nbsp; (et sett med shell funksjoner for å forenkle bruken av virtualenv).
Utvikler kommentarer
Som mange, har jeg brukt virtualenvwrapper i årevis, men det er blitt litt tung over tid. Jeg fant til slutt meg selv venter for lenge på nye skjell for å starte opp, selv om jeg hadde en tendens til å bruke bare de grunnleggende funksjonene.
Dette prosjektet er et forsøk på å løse det problemet. Jeg lånte den smarte biter av virtualenvwrapper, forkastet alt jeg vurdert dyrt eller bare ikke interessant, og lagt til en funksjon eller to av mine egne. Nummer én prioritet med dette prosjektet er hastigheten. Koden er nesten ren shell script, selv om det kan være en eller to besvergelser av standard verktøy som grep eller sed.
Bli advart om at denne implementeringen kanskje ikke for deg. Jeg kan ha blitt kvitt en funksjon som du likte, enten fordi det var dyrt eller fordi jeg bare ikke bryr seg om det. Jeg kan ha et uhell forkastet en reparasjon eller omgåelse for noen miljø som jeg ikke har møtt. Jeg har kanskje nettopp introdusert nye feil (skallet er et enkelt språk å få feil på subtile måter). Fortsett på egen risiko.
Installere
virtualenv-sh kan installeres med pip eller easy_install. Å bruke den, må du kilden et enkelt shell skript i din shell miljø. Som standard, pip eller easy_install bør installere det til / usr / local / bin. Hvis du bruker bash eller zsh, bør du importere skallet spesifikke script; ellers, kan du prøve den generiske ett. Legg ett av følgende i skallets init script (.bashrc, .zshrc, etc.):
. /usr/local/bin/virtualenv-sh.bash
. /usr/local/bin/virtualenv-sh.zsh
. /usr/local/bin/virtualenv-sh.sh
Ingenting annet er nødvendig. Det er bare én miljøvariabelen som du kan bruke for konfigurering, som er WORKON_HOME. Dette er en bane til din samling av virutalenvs; du kan la det stå tomt for å godta standard på $ {HJEMME} /. virtualenvs. Det antas at virtualenv selv er i din vei.
WORKON_HOME = $ {home} /. Virtualenvs
zsh

Hvis du bruker zsh, kan du i stedet bruke den ferdigbygd funksjon arkiv for optimal ytelse, selv om dette må kompileres fra kilden på din maskin. Du kan laste ned kilde direkte eller prøve:
 PIP installere --upgrade --no-installere virtualenv-sh
cd build / virtualenv-sh
sudo make install
Dette vil finne zsh på din vei, bruke den til å kompilere virtualenv-sh.zwc, og installer den til / usr / local / bin. Du kan nå Autostart disse funksjonene og initial virtualenv-sh. Det kan være lurt å se avsnittet om funksjonen autoloading i zsh manuell hvis du ikke er kjent med denne prosessen:
# Konfigurer alle virtualenv-sh funksjoner for autoloading
fpath = (/ usr / local / bin / virtualenv-sh $ fpath)
autoload-w / usr / local / bin / virtualenv-sh
# Ring hoved initialisering funksjon
virtualenv_sh_init
Bruk
De grunnleggende kommandoer virtualenv-sh er i hovedsak de samme som virtualenvwrapper. Her er en kort oppsummering:
& Nbsp; mkvirtualenv
& Nbsp; Oppretter en ny virtual_env i $ WORKON_HOME. Alle argumentene er gått direkte til virtualenv. Den nye virtual_env vil bli aktiv. I motsetning virtualenvwrapper, dette tar ingen ekstra argumenter.
& Nbsp; rmvirtualenv
& Nbsp; Sletter en eksisterende virtual_env. Hvis dette virtual_env er aktive, er det først deaktiveres som en tjeneste.
& Nbsp; workon []
& Nbsp; Aktiverer den navngitte virtual_env. Hvis en annen virtual_env er aktive, vil den bli deaktivert først. Uten argumenter, vil det liste opp tilgjengelige virtual_envs.
& Nbsp; autoworkon
& Nbsp; setter automatisk virtual_env basert på spesielle filer. Se under.
& Nbsp; deaktivere
& Nbsp; Deaktiverer gjeldende virtual_env (som når du bruker virtualenv direkte).
& nbsp; lsvirtualenvs
& Nbsp; Skriver ut en liste over de virtual_envs du har opprettet.
& Nbsp; cdvirtualenv [subdir]
& Nbsp; Endrer gjeldende mappe til roten av den aktive virtual_env, eller en underkatalog av disse.
& nbsp; lssitepackages
& Nbsp; Lister innholdet i den aktive virtual_env sin site-pakker katalogen.
& Nbsp; cdsitepackages [subdir]
& Nbsp; Endrer currect katalogen til site-pakker katalog av den aktive virtual_env, eller en underkatalog av disse.
Hooks
virtualenv-sh støtter de samme globale og lokale (per-env) kroker som virtualenvwrapper. Globale kroker er filer i $ WORKON_HOME; lokale kroker er filer i $ WORKON_HOME / {virtual_env} / bin. Kroker er henrettet ved sourcing dem i dagens skallet sammenheng.
& Nbsp; initial (global)
& Nbsp; Kalt på slutten av virtualenv_sh_init.
& Nbsp; premkvirtualenv, postmkvirtualv, prermvirtualenv, postmkvirtualenv (global)
& Nbsp; Kalt på begynnelsen og slutten av mkvirtualenv og rmvirtualenv.
& Nbsp; preactivate, postactivate (global, lokal); predeactivate, postdeactivate (lokal, global)
& Nbsp; Kalt i angitt rekkefølge rundt aktivering og deaktivering av en virtual_env.
I tillegg gir virtualenv-sh du dynamisk registrere funksjoner som skal kalles ved utføring kroker:
virtualenv_sh_add_hook
virtualenv_sh_remove_hook
f.eks .:
my_virtualenv_cleanup ()
{
& Nbsp; # Gjør noen ting her
}
virtualenv_sh_add_hook postdeactivate my_virtualenv_cleanup
Registrerte krok funksjoner er alltid utføres etter alle globale og lokale påhakningsskript.
autoworkon
autoworkon er en ny kommando som er utformet for å automatisk oppdatere virtual_env basert på din nåværende katalog. Legg merke til at det ikke er standard shell mekanisme for å kjøre en funksjon når gjeldende katalog endringer - og mange skall ikke har en slik mekanisme - så installerer dette er opp til deg. Hvis du bruker zsh, ville du bruke:
autoload -u add-krok zsh-
add-krok zsh-chpwd autoworkon
Den autoworkon funksjonen vil gå opp filsystemet fra gjeldende mappe til den enten når roten eller finner et element som heter ".workon". Hvis dette er en lesbar fil, vil den behandle den første linjen som navnet på en virtual_env og aktivere den. Det er et par spesielle regler å huske på:
- Autoworkon stopper alltid ved første .workon den finner. Det er helt rimelig å ha .workon filer på flere punkter i en katalogtreet til å bruke forskjellige virtual_envs på ulike nivåer.
- En tom eller uleselig .workon fil blir tolket som "nei virtual_env". Dette er nyttig hvis du ønsker å deaktivere den automatiske virtual_env i en bestemt subtre.
- Hvis du aktiverer en virtual_env manuelt, vil autoworkon aldri overstyre den. . autoworkon vil bare endre din aktive virtual_env hvis det er unset eller ble tidligere satt av autoworkon

Krav :

• Python