Skip to content
This repository has been archived by the owner on Mar 31, 2024. It is now read-only.

Define Python packaging policy and best practices #37

Open
ermo opened this issue Sep 30, 2022 · 2 comments
Open

Define Python packaging policy and best practices #37

ermo opened this issue Sep 30, 2022 · 2 comments
Labels
chat: brainstorming Wild ideas to spur on the inspiration.

Comments

@ermo
Copy link
Member

ermo commented Sep 30, 2022

There are ongoing experiments related to packaging Python in the temporary snekpit/venom recipe repository.

These experiments have uncovered a number of issues that need to be addressed.

This issue is meant as a tracker issue for sub-tasks that need to be resolved before we're happy with our Python packaging policy and associated tooling requirements.

Existing tasks:

PRs:

@ermo
Copy link
Member Author

ermo commented Sep 30, 2022

@sunnyflunk:

I'm tentatively assigning this to you. If you don't feel like now is the correct time to take a look at it for whatever reason, just unassign yourself and we can pick it up at a later point. =)

@sunnyflunk
Copy link
Contributor

Essentially what needs to happen is to determine a bootstrap process that can apply to any bootstrap (say having $pkg/stone-stage1.yml as a 1st bootstrap build and then rebuild the stone.yml's once the -stage1's are all done). This will be essential for bringing up new architechtures and being consistent across all tooling and packages will make things a lot simpler.

The 2nd step is then to apply the bootstrap process to the python packages as it will need rebootstrapping with every version upgrade.

@livingsilver94 livingsilver94 added the chat: brainstorming Wild ideas to spur on the inspiration. label Jul 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
chat: brainstorming Wild ideas to spur on the inspiration.
Projects
None yet
Development

No branches or pull requests

3 participants