On Mon, Jul 25, 2016 at 8:55 AM, Robin Becker <ro...@reportlab.com> wrote:
> In our private readonly pypi we have 93 releases. I don't think that > burden should fall on pypi. However, it's not clear to me if I should push > micro releases to pypi and then remove them when another release is made. > Is there a way to remove a 'release' completely? I'm pretty sure there is no way to remove a release (at least not routinely). thi sis by design -- if someone has done something with that particular release, we want it to be reproducible. I see the point, but it's a little be too bad -- I know I've got some releases up there that were replaced VERY soon due to a build error or some carelessness on my part :-) Apparently, disk space is cheap enough that PyPI doesn't need to worry about it. Are you running into any problems? I did try to reduce my manylinux sizes by using a library of shared object > codes (ie a .a built from the PIC compile objs), but I didn't seem able to > make this work properly; the resulting .so seems to contain the whole > library (freetype). is this a problem other than file sizes? I think until / if Nathanial (or someone :-) ) comes up with a standard way to make wheels of shared libs, we'll simply have to live with large binaries. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
