On 17 May 2015 at 23:50, Chris Barker 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 folks.
Agreed. My per
On 18 May 2015 at 05:32, David Cournapeau 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.
One way forwa
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 e
On 18 May 2015 at 18:50, David Mertz 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 provided as conda p
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 sho
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 wrote:
> One way forward in terms of building wheels is to use any build
> process you like to do an isolated build (I think it's -
On Mon, May 18, 2015 at 11:21 AM, Paul Moore wrote:
> On 18 May 2015 at 18:50, David Mertz 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
On Mon, May 18, 2015 at 10:50 AM, David Mertz 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
> into pip.
>
I a
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
Tha
> 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,
10 matches
Mail list logo
