This pertains more to the other thread I started, but I'm sort of becoming
convinced--especially by Paul Moore's suggestion there--that the better
approach is to grow conda (the tool) rather than shoehorn conda packages
into pip. Getting pip to recognize the archive format of conda would be
easy
On 18 May 2015 at 18:50, David Mertz dme...@continuum.io wrote:
% pip install conda
% conda install scientific_stuff
% conda install --sdist django_widget # we know to look on PyPI
But that doesn't give (Windows, mainly) users a solution for things
that need a C compiler, but aren't
I don't really see any reason conda couldn't support bdist wheels also.
But yes, basically the idea is that we'd like users to be able to rely
entirely on conda as their packaging (and environment configuration) system
if they choose to. It may be impolitic to say so, but I think conda can
and
On Mon, May 18, 2015 at 11:21 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 18 May 2015 at 18:50, David Mertz dme...@continuum.io wrote:
% pip install conda
% conda install scientific_stuff
% conda install --sdist django_widget # we know to look on PyPI
But that doesn't give
Hello
I was trying to create my package for distribution. I have a requirement
that I need to check if one particular command is available in the system (
this command is not installed through a package - but a bundle is installed
to get the command in the system ). I am using Ubuntu 14.04
But it gets messy when you have two systems trying to handle dependencies --
pip may not realize that conda has already installed something, and vice
versa. So it's really nicer to have one package manager.
But maybe all you really need to do is teach conda to understand pip
meta-data,
A member of the conda dev team could answer this better than I, but I've
used enough to _think_ I understand the basics:
On Mon, May 18, 2015 at 3:30 AM, Paul Moore p.f.mo...@gmail.com wrote:
One way forward in terms of building wheels is to use any build
process you like to do an isolated
On Mon, May 18, 2015 at 10:50 AM, David Mertz dme...@continuum.io wrote:
This pertains more to the other thread I started, but I'm sort of becoming
convinced--especially by Paul Moore's suggestion there--that the better
approach is to grow conda (the tool) rather than shoehorn conda packages
On 18 May 2015 at 05:32, David Cournapeau courn...@gmail.com wrote:
Note that some packages will push hard against injecting setuptools, at
least until it does not offer a way to prevent from installing as an egg
directory. Most of the core scientific packages avoid setuptools because of
this.
On 17 May 2015 at 23:50, Chris Barker chris.bar...@noaa.gov wrote:
I guess the key thing here for me is that I don't see pushing conda to
budding web developers -- but what if web developers have the need for a bit
of the scipy stack? or???
We really don't have a good solution for those
10 matches
Mail list logo
