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

Add more output formats (Docker, conda-pack)

Aperta
  • Qualcosa non va?
#730 2 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
docker, python
Ambito
build-system, release

Direzione di ricerca

Inizia esaminando construct.yml e i percorsi di codice esistenti di constructor per i formati degli installer, quindi confronta i flussi proposti degli artefatti container e conda-pack. Determina se la configurazione e i concetti attuali possono supportare questi formati o se è necessario uno strumento separato; il lavoro è completo quando sono documentati una decisione di fattibilità e un ambito definito.

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

Descrizione

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

constructor is able to generate installers for Linux, macOS, and Windows, using an array of formats (SH, PKG, EXE, respectively). However, there's nothing special about these "installers" they are just "artifacts" that "pack" a number of conda packages.

The idea here would be to teach constructor how to generate additional artifact formats, like:

  • Docker containers via conda-docker
  • Tarballs via conda-pack
Why is this needed?

constructor would slowly become an interface for packaging and distributing conda environments. There is plenty of duplicated logic across this projects and we would benefit from a single maintenance hub for all of them. There are bits of conda-pack internals that would be lovely to have in constructor's code (like the Environment abstraction).

What should happen?

Users could just have a construct.yml like this:

name: Scripts
version: X
# installer_type: all
artifacts:
  - container  # via conda-docker
  - conda-pack
channels:
  - http://repo.anaconda.com/pkgs/main/
specs:
  - python
Additional Context

This is the other side of https://github.com/conda/conda-pack/issues/294.

We could take a look and see how feasible this is. constructor was always built with the "installer" idea in mind, so some concepts in the config file and code base might be too coupled. In that case, a separate tool that encompasses all these usages with their nuances could be better welcome (e.g. conda-bundle).

Lingua principale
Python
Stelle
500
Fork
185
Merge medio
7h 44m
PR unite (30g)
15

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.