search

groove-x / trio-util

Utility library for the Python Trio async/await framework
https://trio-util.readthedocs.io/
MIT License
68 stars 6 forks source link

Add MANIFEST.in to include license file in source distribution #11

Closed synapticarbors closed 4 years ago

synapticarbors commented 4 years ago

It would be helpful to include the license file in the source distribution.

dhirschfeld commented 4 years ago

@belm0 - as a conda user I've taken the liberty of packaging trio-util for conda-forge: https://github.com/conda-forge/trio-util-feedstock

I'm happy to maintain the feestock going forward but just let me know if you'd like to also be added as a maintainer?

After feedstock creation, updates are mostly automatic with maintenance just consisting of ensuring deps are kept in sync.

belm0 commented 4 years ago

@dhirschfeld thank you-- I haven't encountered conda yet so I'll defer to you on maintenance

I do have debian packaging experience, so I'm curious about this. Naive observation on conda:

Couldn't 95% of python packages be handled without a dedicated recipe repo, and without a manually generated meta.yaml?

I mean, there could just be a single conda repo with the metadata for these simple package cases, and the metadata could be updated automatically from setuptools whenever the maintainer wants to track a new version. (Maybe like OS X homebrew.). Having a repo per upstream package, with all those boilerplate files, seems like high overhead...

dhirschfeld commented 4 years ago

For simple, python-only, packages that might work 99% of the time but since that wouldn't work for a lot of packages I guess it's easier to maintain one way to do it and to provide tooling which helps to do that in the simple cases.

grayskull is an example of that - it's a CLI that can create a meta.yaml for you from pypi metadata. The conda forge bot also automatically opens PRs for you but it doesn't (yet) automatically update dependencies. It does try and suggest changes in dependencies though.

conda and conda-forge are also relatively young. conda-forge has shown up some problems with conda and the way it was implemented - I don't think something like conda-forge was envisaged by the conda devs when they started out to build a package manger that could handle compiled dependencies for scientific python packages. Things aren't stationary though - both conda and the conda packaging spec are evolving to address some of the pain-points highlighted by conda-forge.