virtualenvwrapper for csh?
Erik Bray
I only recent started using virtualenvwrapper, and I have to say I
don't know how I ever lived (okay, used virtualenv) without it. Great
work!
Unfortunately, at my organization csh (tcsh, technically) is the
default environment for developers on Linux and I think even OSX.
It's for deeply ingrained historical issues, and is not likely to go
away any time in the immediate future (though users can request the
sysadmin to change their login shell to bash, many don't bother).
So I want evangelize virtualenvwrapper (not to mention virtualenv
which not many people are using), but it's not likely to gain as much
traction without csh support. I'm happy to try to get that working
myself, but before I dig too much more into the effort I just want to
make sure no one else has done it. A bit of Googling seems to suggest
"no", but just making sure it's not out there somewhere in a hard to
find place.
Thanks,
Erik
Doug Hellmann
As far as I know, no one has done a port to a csh-based shell syntax. It should be possible, but it's not likely to result in a single version of virtualenvwrapper.sh that can run under both bash and tcsh. We can discuss including a virtualenvwrapper.csh (or similarly named) port in the main distribution, if the results are otherwise compatible with the hook loader code.
Keep me posted!
Doug
Erik Bray
avoid the setup.py from having to guess which one you intend to
actually use, it just installs it alongside virtualenvwrapper.sh. I
haven't looked at the hook loader code yet, so I'm not sure what will
be required to maintain compatibility there. To really do this right
it will also be necessary to port most if not all of the tests. My
fork is here, though there's nothing to see yet:
https://bitbucket.org/embray/virtualenvwrapper-csh
My hope is someone will pop up and say, "Hey, I've already done
this!" but it doesn't seem likely. csh scripting is not my idea of a
good time :)
Thanks,
Erik
Erik Bray
> To really do this right
> it will also be necessary to port most if not all of the tests.
probably also need to support csh, an effort I probably don't have
time to devote to right now. Oh well, as long as I can get
virtulenvwrapper working for my most common use cases it should be
fine. Most of the changes should be syntactic in nature. I just
worry about edge cases.
Erik
Doug Hellmann
Right, it's the edge cases that kill you.
I've been meaning to port the tests to another tool (possibly cram, if it proves to be suitable). Maybe this is an excuse to finally do it.
Erik Bray
Testing shell scripts is a problem I've never really dealt with
before, but cram seems nice. It's shell-agnostic anyways. It's neat
how shunit2 has a familiar unittest-like API, but it also seems like a
lot more work than the simple functional testing approach of cram.
Erik
Doug Hellmann
Right. I found shunit2 before cram, so that's how I ended up using it. I haven't had an actual need to change until this point, so I didn't put the work into it.
Erik Bray
features complete. I'm using it without any obvious issues. Hook
scripts are working AFAICT. The implementation is a bit hackish in
order to deal with the idiosyncrasies of csh. In particular, it adds
a .virtualenvwrapper.csh directory full of scripts that implement the
individual virtualenvwrapper functions. This is much easier to deal
with than and more reliable than trying to cram everything into
aliases. Also, the tab-completion feature isn't ported since I don't
think it's possible to implement for csh.
If you want to take a look my fork is at https://bitbucket.org/embray/virtualenvwrapper-csh
Thanks,
Erik
Doug Hellmann
On Aug 26, 2011, at 1:07 PM, Erik Bray wrote:
> On Aug 16, 3:50 pm, Doug Hellmann <doug.hellm...@gmail.com> wrote:
>> On Aug 16, 2011, at 3:31 PM, Erik Bray wrote:
>>> Greetings,
>>
>>> I only recent started using virtualenvwrapper, and I have to say I
>>> don't know how I ever lived (okay, used virtualenv) without it. Great
>>> work!
>>
>>> Unfortunately, at my organization csh (tcsh, technically) is the
>>> default environment for developers on Linux and I think even OSX.
>>> It's for deeply ingrained historical issues, and is not likely to go
>>> away any time in the immediate future (though users can request the
>>> sysadmin to change their login shell to bash, many don't bother).
>>
>>> So I want evangelize virtualenvwrapper (not to mention virtualenv
>>> which not many people are using), but it's not likely to gain as much
>>> traction without csh support. I'm happy to try to get that working
>>> myself, but before I dig too much more into the effort I just want to
>>> make sure no one else has done it. A bit of Googling seems to suggest
>>> "no", but just making sure it's not out there somewhere in a hard to
>>> find place.
>>
>> As far as I know, no one has done a port to a csh-based shell syntax. It should be possible, but it's not likely to result in a single version of virtualenvwrapper.sh that can run under both bash and tcsh. We can discuss including a virtualenvwrapper.csh (or similarly named) port in the main distribution, if the results are otherwise compatible with the hook loader code.
>>
>> Keep me posted!
>>
>
> Well, I've got my port to [t]csh pretty much working now with all
> features complete. I'm using it without any obvious issues. Hook
Nice!
> scripts are working AFAICT. The implementation is a bit hackish in
> order to deal with the idiosyncrasies of csh. In particular, it adds
> a .virtualenvwrapper.csh directory full of scripts that implement the
> individual virtualenvwrapper functions.
That may not work for all of the functions. The reason I used functions instead of separate scripts is that many of them (esp. workon) change the environment settings of the current shell, and that isn't possible from a subprocess.
> This is much easier to deal
> with than and more reliable than trying to cram everything into
> aliases. Also, the tab-completion feature isn't ported since I don't
> think it's possible to implement for csh.
It isn't for csh, but tcsh does support tab completion, IIRC.
>
> If you want to take a look my fork is at https://bitbucket.org/embray/virtualenvwrapper-csh
I am traveling this weekend, but will try to take a look next week.
What did you do about tests? I know we talked about shunit2 not working with csh. Did you try cram?
Thanks for your work on this,
Doug
Erik Bray
>> Well, I've got my port to [t]csh pretty much working now with all
>> features complete. I'm using it without any obvious issues. Hook
>
> Nice!
>
>> scripts are working AFAICT. The implementation is a bit hackish in
>> order to deal with the idiosyncrasies of csh. In particular, it adds
>> a .virtualenvwrapper.csh directory full of scripts that implement the
>> individual virtualenvwrapper functions.
>
> That may not work for all of the functions. The reason I used functions instead of separate scripts is that many of them (esp. workon) change the environment settings of the current shell, and that isn't possible from a subprocess.
The sub-scripts have to be sourced in order to work, of course. What
were functions in the original virtualenvwrapper are replaced with
aliases that basically read, for example:
alias workon 'source ${VIRTUALENVWRAPPER_SCRIPT_DIR}/workon'
It's ugly, but it's really the best way to do this in csh since there
is no support for functions. It also means that all local variables
created by the sub-script need to be manually cleaned up, but it's
pretty careful about that. A few of the scripts run in subshells but
any that need to modify the environment don't.
>> This is much easier to deal
>> with than and more reliable than trying to cram everything into
>> aliases. Also, the tab-completion feature isn't ported since I don't
>> think it's possible to implement for csh.
>
> It isn't for csh, but tcsh does support tab completion, IIRC.
tcsh supports some primitive tab completion for variable and file
names. It doesn't have any way to set up custom completion for
arbitrary commands like bash has :/
> I am traveling this weekend, but will try to take a look next week.
>
> What did you do about tests? I know we talked about shunit2 not working with csh. Did you try cram?
I haven't done anything with tests--my only testing has been along the
lines of "it's working for my daily use". If I have time I can play
around with cram at some point.
Thanks,
Erik
Doug Hellmann
On Aug 29, 2011, at 11:13 AM, Erik Bray wrote:
> On Fri, Aug 26, 2011 at 4:09 PM, Doug Hellmann <doug.h...@gmail.com> wrote:
>>> Well, I've got my port to [t]csh pretty much working now with all
>>> features complete. I'm using it without any obvious issues. Hook
>>
>> Nice!
>>
>>> scripts are working AFAICT. The implementation is a bit hackish in
>>> order to deal with the idiosyncrasies of csh. In particular, it adds
>>> a .virtualenvwrapper.csh directory full of scripts that implement the
>>> individual virtualenvwrapper functions.
>>
>> That may not work for all of the functions. The reason I used functions instead of separate scripts is that many of them (esp. workon) change the environment settings of the current shell, and that isn't possible from a subprocess.
>
> The sub-scripts have to be sourced in order to work, of course. What
> were functions in the original virtualenvwrapper are replaced with
> aliases that basically read, for example:
>
> alias workon 'source ${VIRTUALENVWRAPPER_SCRIPT_DIR}/workon'
>
> It's ugly, but it's really the best way to do this in csh since there
> is no support for functions. It also means that all local variables
> created by the sub-script need to be manually cleaned up, but it's
> pretty careful about that. A few of the scripts run in subshells but
> any that need to modify the environment don't.
Ah, that makes sense. I didn't realize that csh didn't support functions.
>
>>> This is much easier to deal
>>> with than and more reliable than trying to cram everything into
>>> aliases. Also, the tab-completion feature isn't ported since I don't
>>> think it's possible to implement for csh.
>>
>> It isn't for csh, but tcsh does support tab completion, IIRC.
>
> tcsh supports some primitive tab completion for variable and file
> names. It doesn't have any way to set up custom completion for
> arbitrary commands like bash has :/
OK.
>> I am traveling this weekend, but will try to take a look next week.
>>
>> What did you do about tests? I know we talked about shunit2 not working with csh. Did you try cram?
>
> I haven't done anything with tests--my only testing has been along the
> lines of "it's working for my daily use". If I have time I can play
> around with cram at some point.
Sounds good. How do you feel about publicizing it and letting some other people use it before we merge it in to the main distribution? I would want to make sure the tests were in place before then anyway, but having more users may also attract other people to help with tests.
Doug