On 4 December 2013 21:10, Nick Coghlan ncogh...@gmail.com wrote:
== Regarding conda ==
In terms of providing an answer to the question Where does conda fit
in the scheme of packaging tools?, my conclusion from the thread is
that once a couple of security related issues are fixed (think PyPI
On 6 December 2013 13:54, Nick Coghlan ncogh...@gmail.com wrote:
On 4 December 2013 21:10, Nick Coghlan ncogh...@gmail.com wrote:
== Regarding conda ==
In terms of providing an answer to the question Where does conda fit
in the scheme of packaging tools?, my conclusion from the thread is
On 7 December 2013 00:05, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 6 December 2013 13:54, Nick Coghlan ncogh...@gmail.com wrote:
On 4 December 2013 21:10, Nick Coghlan ncogh...@gmail.com wrote:
I think this is important enough to warrant a NumPy and the
Scientific Python stack
On Fri, Dec 6, 2013 at 6:22 AM, Nick Coghlan ncogh...@gmail.com wrote:
I created a draft of this new section at
https://bitbucket.org/pypa/python-packaging-user-guide/pull-request/12/recommendations-for-numpy-et-al/diff
looks good, thanks!
ONe note:
In particular, bootstrapping conda
On 7 December 2013 03:44, Chris Barker chris.bar...@noaa.gov wrote:
On Fri, Dec 6, 2013 at 6:22 AM, Nick Coghlan ncogh...@gmail.com wrote:
I created a draft of this new section at
https://bitbucket.org/pypa/python-packaging-user-guide/pull-request/12/recommendations-for-numpy-et-al/diff
On 4 December 2013 23:25, Daniel Holth dho...@gmail.com wrote:
On Wed, Dec 4, 2013 at 6:10 AM, Nick Coghlan ncogh...@gmail.com wrote:
== Regarding custom installation directories ==
This technically came up in the cobblerd thread (regarding installing
scripts to /usr/sbin instead of
On 5 December 2013 00:06, Marcus Smith qwc...@gmail.com wrote:
but Anoconda does some a nifty thing: it make s conda package that holds
the shared lib, then other packages that depend on it depend on that
package, so it will both get auto--installed
But I don't see why you couldn't do that
There was some really good feedback in the binary dependency thread,
but it ended up going off on a few different tangents. Rather than
expecting people to read the whole thing, I figured I'd try to come up
with a summary of where it has gone so far, and where we might want to
take it from here.
On Wed, Dec 4, 2013 at 6:10 AM, Nick Coghlan ncogh...@gmail.com wrote:
There was some really good feedback in the binary dependency thread,
but it ended up going off on a few different tangents. Rather than
expecting people to read the whole thing, I figured I'd try to come up
with a summary
- a richer platform tagging mechanism (which we need for *nix systems
anyway)
- a way to ensure internal consistency of the installed *builds* in an
environment, not just the abstract dependencies
I've opened a wheel format definition issue for the first problem:
pip install --tag=continuum-super-science-stack_x86_64 --index-url=
http://continuum/wheels numpy
CORRECTION: drop the _x86_64. that wouldn't be needed with properly
packaged wheels.
___
Distutils-SIG maillist - Distutils-SIG@python.org
ok, but could/would the pip/wheel toolchain ever expand itself to handle
delivery of external dependencies (like qt, tk, and numpy's fortran
stuff).
fortran stuff is pretty poorly defined -- I'm not sure we'd ever want
pip to install a fortran compiler for you
to be very literal,
12 matches
Mail list logo
