2020-05-27 | conda-forge | community-driven packaging for conda

(all) intros for new people on the line?

Marcelo!

(CJ) standing budget item

(CJ) institutional partners metadata (https://github.com/conda-forge/conda-forge.github.io/pull/1028)

(ED) Should we just merge in the cfep PRs with the status of "deferred" since there's zero action on any of them?

(MRB) change how we mark packages as broken

currently we move packages to broken and remove them from main
- this means users cannot recreate old envs where a package was marked as broken
new system would leave packages on main (only add broken label) and then remove them via the removals section of the repo data patches
- this is how defaults does it
do we need to announce this before switching? should we switch?
side effects are that this procedure leaves the repodata in weird states
- the only source of truth is the one on the CDN (any other source is wrong)
- packages can have different looking requirements between broken and main labels even on the CDN
matching defaults is probably more important than the things above
TODO:
- document how users are supposed to interpret broken label
- update how we, as core, are supposed to mark packages as broken
- (ED) document strategies for reproducible environments using conda-forge

(CJ) I'd like to form a finance subteam, if you are interested in serving please let me know.

numfocus point of contact
responsible for letting core know where we stand financially
pending financial matters
acting as final approvers

(JJH) Should tk require freetype and X11? https://github.com/conda-forge/tk-feedstock/pull/40

Fonts will look nicer in TK applications
Introduces new requirements (and download/disk space) to Python
- fontconfig: 300kb, freetype: 1mb
- some additional packages needed as well
Recommendation is to create two variants, with and without "nice fonts"

(IF) Making a linux-anvil-ppc64le package and distributing cudatoolkit in the docker image

https://github.com/conda-forge/docker-images/pull/113
There's no defaults::cudatoolkit for ppc64le, but the docker image is still useful to have
Even though we can't redistribute defaults::cudatoolkit we are doing it via docker as we are caching it.
Notes:
- Make it clear to users that this docker image doesn't have cudatoolkit and why it doesn't have cudatoolkit.

(WV) "standardization" of a next gen package format and other parts of the conda ecosystem

Make available specs public? E.g: https://anaconda.atlassian.net/wiki/spaces/AD/pages/90210540/Conda+package+format+v2
Some notes regarding a next version of the package spec are written down here: https://hackmd.io/axI1tQdwQB2pTJKt5XdY5w
- this current spec doesn't support everything one needs for the current stack
also some discussion on gitter and at bot subteam meeting a few months ago
- using python as the language came up more than once
  - objections are that it is not static metadata and might be too hard to parse
- deprecate selectors in favor of ...
  - jinja2 if statements (hard to parse)
  - letting any value in the config be a dict with the selector info in the key
    - this follows what rust does in their TOML
    - very easy to parse
    - always results in valid YAML
- deprecate the use of some jinja2 elements (any control flow elements) since they are hard to parse
related to the conda working group that Kale is organizing
Interest
- Jonathan Helmus
- Wolf
- Marcel
- Scopatz
  - specifically interested in the activation scripts
- Cheng?
- Matt B.
- Marcelo
- Mike S.
- John

(UK) static libraries in conda-forge

Our toolstack and systems are tailored for dynamic linkage, thus we want to focus on that in conda-forge
Users are interested in static libraries for some use cases, e.g.
- Building wheels for PyPI on Windows
- (MRB) Do we want to make a better effort to support this? Marking static packages and doing small migrations when we move compilers as needed? Our answer has been no. (UK: Note that the reported breakages were because of LTO- enabled static libraries, that's a next level)
- static libraries can have compatibility concerns with compilers and ld/binutils
Go and Rust are separate discussions (packaging and licensing, etc.)
What do we do about accidental leakage?
- remove them or mandate a split package
Add linting hints to builds to find them
Recommend how to package them
We should write docs saying we don't provide support and this is a bad idea.

2020-05-27 conda-forge core meeting

Attendees

Agenda

Your agenda items

Active votes

Subteam updates

Bot

Stuff from last week that we didnt get to

ARM

POWER

CUDA

Docs

staged-recipes

website

security+systems

CI infrastructure

Compiler upgrade

CFEP updates

Open PRs

Discussion

Check in on previous action items

Last meeting

3 meetings ago

Move to Issue Tracker

Attendees​

Agenda​

Your agenda items​

Active votes​

Subteam updates​

Bot​

Stuff from last week that we didnt get to​

ARM​

POWER​

CUDA​

Docs​

staged-recipes​

website​

security+systems​

CI infrastructure​

Compiler upgrade​

CFEP updates​

Open PRs​

Discussion​

Check in on previous action items​

Last meeting​

3 meetings ago​

Move to Issue Tracker​