styxman / ayrton Goto Github PK

with ayrton (): ...

We can't implement all of ssh's options, so we better let the command be executed and have something else for with ssh(): ...

see pdb's source

We got rid of source in favor of import, but import does not handle .ay files.

When executing remote() code, we're currently passing only the local variables, but not much more. This means that any class, function or module used in the remote() code must somehow redefine those things. The simplest way would be to pass the ASTs for the (local) classes and functions, plus make sure to reimport anything needed (and pray that the modules are present in the remote host).

Hey all, I am one of the xonsh developers, and I wanted to say that this is a very cool project. I especially like the idea of a remote execution context manager. Definitely going to be putting that into xonsh :).

However, I did want to offer one point of clarification. In the readme it says:

xonsh keeps environment variables well separated from Python ones;

This is not strictly speaking true. While we do make a syntactic distinction between internal-whitespace-insensitive "python-mode" and internal-whitespace-sensitive "subprocess-mode", the distinction isn't so clean. We actually extend Python mode in a couple of ways through operators like $ for environment lookup, ? for help, ?? for super help, $() and $[] for subprocesses, and backtick regex strings. These are all in python mode. If an environment variable $VAR is a Python list, you can do things like $VAR[::-1] or any other valid list operation.

On the other hand, in subprocess-mode, aliases can be Python functions that are called with arguments that are passed in. They never see an actual subprocess in such cases.

In essence, xonsh focuses on being a shell, as you say. But it tries to make it easy to migrate between these two modes. If you could please modify the text of the readme to reflect this, I'd greatly appreciate it!

we're currently talking to the remote through the 3 streams returned by paramiko's SSHClient.run_command(). try to make it look more like sh's Command interface.

try:

mcedit ()

from foo import bar is gonna break.

Exception TypeError: "'NoneType' object is not callable" in <bound method ChannelStderrFile.__del__ of <paramiko.ChannelFile from <paramiko.Channel 1 (open) window=2096000 -> <paramiko.Transport at 0x9b8b4f50 (unconnected)>>>> ignored
Exception TypeError: "'NoneType' object is not callable" in <bound method ChannelFile.__del__ of <paramiko.ChannelFile from <paramiko.Channel 1 (open) window=2096000 -> <paramiko.Transport at 0x9b8b4f50 (unconnected)>>>> ignored
Exception TypeError: "'NoneType' object is not callable" in <bound method ChannelFile.__del__ of <paramiko.ChannelFile from <paramiko.Channel 1 (open) window=2096000 -> <paramiko.Transport at 0x9b8b4f50 (unconnected)>>>> ignored

It doesn't happen always.

amoffat/sh#66

just recently i wanted something like this.

the python syntax + piping alone is worth the switch.

I'm curious how robust it is nowaddays. I see development has slowed down-- but that might just mean it's done ;)

while trying to run the tests:

File "ayrton/functions.py", line 22, in
import paramiko
File "/home/mdione/.local/lib/python3.2/site-packages/paramiko/init.py", line 64, in
from .transport import SecurityOptions, Transport
File "/home/mdione/.local/lib/python3.2/site-packages/paramiko/transport.py", line 33, in
from paramiko import util
File "/home/mdione/.local/lib/python3.2/site-packages/paramiko/util.py", line 33, in
from paramiko.common import *
File "/home/mdione/.local/lib/python3.2/site-packages/paramiko/common.py", line 102, in
from Crypto import Random
ImportError: No module named Crypto