Message311309
| Author | josh.r |
|---|---|
| Recipients | Decorater, Marcus.Smith, brett.cannon, christian.heimes, dstufft, eric.snow, gregory.p.smith, josh.r, ncoghlan, ned.deily, njs, paul.moore, pitrou, ronaldoussoren, steve.dower, tim.golden, zach.ware |
| Date | 2018-01-31.01:38:16 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1517362700.02.0.467229070634.issue32387@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
So, just for clarity, is there another approved mechanism for distributing an extension that just happens to act as a (Python version specific) C support library? I've wanted to be able to build a library (static or dynamic) that is installed to lib/pythonX.Y/site-packages so it can be found by other extensions that use it without them having to ship a copy themselves. The best solution I found was building and installing untagged extensions with pip; the extension features weren't actually used for anything but unittesting the library, but making it an extension meant it got installed to the Python version specific site-packages. If untagged extensions aren't just old-fashioned, but banned, my use case is broken, and I've been completely unable to find a decent, non-Cython based, setup.py based pattern for building a C library that provides wrappers for Python API calls (and therefore must target specific Python versions). |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2018-01-31 01:38:21 | josh.r | set | recipients: + josh.r, brett.cannon, gregory.p.smith, paul.moore, ronaldoussoren, ncoghlan, pitrou, christian.heimes, tim.golden, ned.deily, njs, eric.snow, zach.ware, steve.dower, dstufft, Marcus.Smith, Decorater |
| 2018-01-31 01:38:20 | josh.r | set | messageid: <1517362700.02.0.467229070634.issue32387@psf.upfronthosting.co.za> |
| 2018-01-31 01:38:19 | josh.r | link | issue32387 messages |
| 2018-01-31 01:38:16 | josh.r | create | |