Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Windows support (without using WSL)

Aperta
  • Qualcosa non va?
#397 4 commenti 2 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@Otto-AA ci sta già lavorando.

Dal 6/7/2025.

  • #404 di @Otto-AA — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
28/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
python
Ambito
operating-systems, testing-qa

Direzione di ricerca

Inizia dal punto di ingresso _run() e traccia i percorsi attuali di os.fork() e resource.RLIMIT_CPU. Confronta gli approcci di multiprocessing proposti e identifica come vengono trasferiti su Windows lo stato di pytest, gli argomenti, gli errori e i timeout. Il lavoro è completato quando è disponibile il supporto nativo per Windows, preservando al contempo le prestazioni, la gestione degli errori e i timeout dei mutanti su Linux e macOS.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Mutmut 3 currently can be run on Windows through the WSL, but not natively on Windows.

We use fork() as a performance optimization, which only works on Unix systems. However, it should be possible to rewrite mutmut to also work with other multiprocessing options. This would be slower (as we cannot copy the whole memory at fork time, including the initialized pytest setup), but still a nice to have.

If someone wants to add native Windows support, we likely need to:

  • rewrite the _run() method to use a the spawn method instead of os.fork()
  • pass all necessary arguments to this process (currently we rely on global + local variables to be copied via forking the whole process memory)

While doing so, we want to ensure that (at least for Linux and MacOS) we have:

  • same performance as before (at least for Linux and MacOS)
  • same test error handling as before (not sure what/how we currently support this. But e.g. what happens a unit test calls os._exit()?)
  • test timeout (currently we use resource.RLIMIT_CPU, which is Unix-only if I'm not mistaken. This is necessary as mutants can easily create infinite loops)

I would consider following approaches, though there may be better ones:

  • create a new process per mutant (as we do now)
  • create max_children worker processes and initialize pytest there. The worker processes keep polling mutation tasks from a Queue and perform them
  • use a multiprocessing.pool.Pool of size max_children and initialize pytest in the setup
Lingua principale
Python
Stelle
1.5k
Fork
182
Merge medio
2g 7h
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di boxed/mutmut

Tutte le issue di boxed/mutmut

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.