Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Unify installer scripts

Đang mở
  • Có gì không ổn?
#968 6 bình luận 1 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
python, shell
Lĩnh vực
build-system, release

Hướng nghiên cứu

Bắt đầu bằng cách lập danh mục các script cài đặt NSIS, .sh đơn lẻ và .pkg hiện có, đồng thời đọc issue #646 về thay đổi NSIS đã được lên kế hoạch. So sánh các lựa chọn Shell và Python về khởi tạo trên Windows, runtime đi kèm, việc dọn dẹp registry và các mối lo ngại về phần mềm chống mã độc. Công việc được xem là hoàn tất khi đã quyết định hướng triển khai và có kế hoạch cụ thể để hợp nhất logic cài đặt dùng chung trong khi vẫn giữ các launcher nhỏ dành riêng cho từng nền tảng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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?
Ngôn ngữ chính
Python
Star
499
Fork
185
Merge trung bình
1 ngày 8 giờ
Pull request đã merge (30 ngày)
19

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của conda/constructor

Tất cả issue của conda/constructor

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.