pytest-dev / pytest-dev/execnet

Record of old ISSUES.txt

Offen
#205 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Vorherrschende Sprache
Python
Sterne
102
Forks
47
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

Removed the old ISSUES.txt file from the repository (773107e305f6799e29d60), creating this issue to record its contents for review in case we want to create actual issues for any of them.


rsync links from posix to windows
-----------------------------------------
tags: 1.1 feature
bb: http://bitbucket.org/hpk42/py-trunk/issue/35
path: execnet/rsync.py

currently rsyncing bails out with a strange message when trying to rsync
links. should provide better message or even some support for doing it.

http process for mediating client/remote-subprocess execution
------------------------------------------------------------------

tags: 1.2 feature newdist

A client client connects to an http-execserver.  An http-execserver
routes incoming "POST /exec" requests to a subprocess and returns a PID.
The PID identifies the subprocess which is used for further communication.

Client             http-exec              subprocess

makegw("...") ->   POST /popen     ->     Popen() with bootstrap
                   (bootstrap)
                   <- PID

c=rexec(...)       POST /exec/PID         exec source
(source)

c.send(1)          POST /exec/PID         x = c.receive()
                   (1)                    assert x == 1
                                          c.send(2)

z = c.receive()    GET /exec/PID
                   <- (2)
assert z == 2

The client connects via "POST /exec/PID"
and pushes data to the remotely-executing code
in the subprocess.

The client connects via "GET /exec/PID"
and receives data from the remotely-executing code.

The client constructs a Channel() object which triggers
these two connections, presenting a nice send/receive
abstractions.

The code executing in the http-execserver controlled
subprocess is a PopenGateway.  It does not know that it
is connected via the http client/server machinery.

The http-execserver proxies data from the subprocess
to the client.  If there is no active GET request, the
data is queued.

The http-execserver forwards data from the client to the
subprocess, using the PID.  If the subprocess is not
connected, an ERROR code is returned.

Example session:

    gw = group.makegateway("http=codespeak.net")

    def fun(channel):
        return channel.send(channel.receive()+1)

    ch = gw.remote_exec(fun)
    ch.send(1)
    x = ch.receive()
    assert x == 2


a channel-IO based gateway
--------------------------------------------------
tags: 1.1 feature newdist

A building block for establishing a permanent hierarchy
of processes is a Gateway that operates on a Channel object.
This way a gateway can be instantiated through another
intermediating gateway which bi-directionallry forwards
Messages through a existing channel.

A code example could look like this:

    group.setlocalfactory(port=8888)
    gw = group.makegateway("ssh=codespeak.net")
    # local ssh-process would be a child of the factory service
    # which could have timeouts for killing, or allow resuming.
    # for instantiating remote it could also install a multiplexer
    # on the remote place such that the same ssh connection is re-used
    # for multiple ssh=codespeak.net connections, makes for small latency.

some first simple implementation might look like this::

    gw = group.makegateway("socketservice//port=8888")
    # we can rely that the subprocess gw can import execnet
    ch = gw.remote_exec("""
        import execnet.service
        execnet.service.gatewaymaker(channel)
    """)
    ch.send(xspec)
    subchannel = ch.receive()
    return ChannelGateway(subchannel)

creating virtualenv environments on the fly
-----------------------------------------------
tags: 1.1 wish

there should be a (plugin-provided?) way to create
a virtual environment:
    gw = makegateway("ssh=codespeak.net")
    newgw = xdeploy.create_venv_gateway(gw, "venvname", depstring)
    newgw # lives in home/ dir of remote virtualenv
          # maybe have get_temproot default to tmp/ there?
    sf = xdeploy.SetupFile("..setup.py")
    sf.sdist_remote_install(newgw)


have callback accept errors / errback
-----------------------------------------------
tags: 1.1 wish

If using channel.setcallback() it currently is not
possible to notice the exact errors that might happen
on the other side.  Either introduce an "errback"
or (probably better) optionally allow an extra 'error'
parameter to execnet callbacks.

fix rsync between python/jython
-----------------------------------------------
tags: 1.0 bug

rsync does not complete with jython.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Dieses Issue ist eher eine Archivaufzeichnung als eine definierte Änderung; der einzige konkret erwähnte Pfad ist execnet/rsync.py, neben mehreren allgemeineren Gateway- und Callback-Ideen. Prüfe zunächst die aufgelisteten Punkte und den aktuellen Projektstatus und teile anschließend alle noch relevanten Arbeiten in separate Issues mit spezifischen Einstiegspunkten, Tests und Akzeptanzkriterien auf.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
python
Bereich
distributed-systems
Issue-Typ
Dokumentation
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Veraltet
Klarheit
Muss geklärt werden
Anfängerfreundlichkeit
10/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.