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

Unify installer scripts

Aperta
  • Qualcosa non va?
#968 6 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
python, shell
Ambito
build-system, release

Direzione di ricerca

Inizia facendo l’inventario degli script di installazione NSIS, .sh singolo e .pkg esistenti, quindi leggi la issue #646 relativa alla modifica NSIS pianificata. Confronta le opzioni Shell e Python rispetto al bootstrap in Windows, ai runtime inclusi, alla pulizia del registro e alle problematiche legate agli anti-malware. Il lavoro è completato quando è stata decisa una direzione di implementazione ed esiste un piano concreto per unificare la logica di installazione condivisa mantenendo piccoli launcher specifici per piattaforma.

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

Descrizione

type::feature
Checklist
  • I added a descriptive title
  • I searched open requests and couldn't find a duplicate
What is the idea?

Constructor's install and uninstall scripts currently exist in 3 versions:

  • NSIS script, for the .exe installer
  • A single .sh script, for the .sh installer
  • A number of separate .sh scripts, for the .pkg installer. These are similar to the single .sh script, but not identical.

Most changes to the installation process must therefore be implemented 3 times.

Since the existing NSIS script will have to be completely rewritten anyway when Constructor moves off NSIS (#646), it’s worth considering whether this is an opportunity to unify all 3 scripts into a single codebase, which would reduce the amount of duplicate maintenance work in the future.

What should happen?

There are two plausible options for which language a unified script could be written in:

Shell script:

  • Would allow us to reuse the existing scripts from the .sh and .pkg formats, which are complete and battle-tested.

  • The main issue is that Windows doesn't come with a Unix-like shell, so a shell executable would need to be bundled with the installer. This doesn't necessarily need to be Bash, since the existing script is already POSIX-compatible, and is verified as such using Shellcheck. A minimal, self-contained POSIX shell such as Dash is probably a better option.

  • Windows would also require implementations of external Unix commands such as rm and cp. Something along the lines of BusyBox is probably the easiest way to provide these. Care would need to be taken to avoid using any versions of these commands which are already on the PATH of the target machine.

Python:

  • Much easier to write secure and reliable code.

  • Would require the installer to bundle a Python interpreter on all platforms. This is already present in installers which use conda-standalone, but not those that use micromamba.

    • However, conda-standalone is already a requirement for most Windows installers, since micromamba doesn't support menuinst.
    • @jaimergp also mentioned that a Python script is already used for some registry cleanup in the Windows uninstaller, because implementing it in NSIS was too difficult. This requires Python to be in the base environment even if it isn't used for anything else.

  • PyInstaller works well on all platforms, and allows us to use a Python build installed by conda from a trusted channel.

    • The install script could be run either:
      • Via the existing conda-standalone executable (conda.exe python); or
      • Via a new PyInstaller executable containing the current conda-standalone functionality plus anything else needed.
    • PyInstaller's main downside is slow startup time because of the initial extraction process. But this could be improved either by:
      • Using PyInstaller's onedir mode rather than onefile; or
      • Doing everything within a single invocation of the executable, so it only has to be extracted once. For example, the script could execute conda commands via function calls if that is supported, or else by launching subprocesses via the Python executable in the PyInstaller temporary directory.

  • MicroPython might be an option, but it appears to be not fully supported on WIndows. And most non-trivial code is not MicroPython-compatible out of the box, which would preclude using any third-party library.

Certain bootstrapping logic would still need to be written in a format supported directly by the OS – i.e. .sh on Linux and macOS, and .bat or .ps1 on Windows. But this would only be a small minority of the total code.

Additional Context

Windows-specific issues:

  • The registry can be accessed using the reg command, so no additional tools or libraries are necessarily required for that.
  • Could shell or Python scripts be blocked by anti-malware systems?
Lingua principale
Python
Stelle
499
Fork
185
Merge medio
1g 8h
PR unite (30g)
19

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 conda/constructor

Tutte le issue di conda/constructor

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.