On Wed, Mar 18, 2015 at 9:02 AM, Ionel Cristian Mărieș
wrote:
>
> On Wed, Mar 18, 2015 at 5:33 PM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
>
>> I don't want it downloading and installing dependencies when I go to
>> build. That's an
On Wed, Mar 18, 2015 at 10:37 AM, Daniel Holth wrote:
> The behavior we're aiming for would be:
>
> "installer run setup.py" - installs things
> "python setup.py" - does not install things
>
yup.
Which, now that I look at it, is not so different than:
python setup.py build # does not isntall a
On Thu, Mar 19, 2015 at 7:12 AM, Daniel Holth wrote:
> ... except that there are plenty of reasons we wouldn't want the
> requirements.txt format, mainly because pip shouldn't automatically
> install concrete dependencies that contain git:// urls etc.
is that format problem, or a pip feature is
On Thu, Mar 19, 2015 at 9:12 AM, Ionel Cristian Mărieș
wrote:
> Worth considering, if you can afford it, to have a local patch that you
> apply before building. Then you have all the necessary fixes (like remove
> the setup_requires) in that patch file.
>
yup -- that's a option -- but a really
On Thu, Mar 19, 2015 at 6:57 AM, Daniel Holth wrote:
> If that's what you want then we could say the spec was to put the
> requirements in setup_requires.txt, in the requirements.txt format,
> which pip would eventually look for and install before running
> setup.py
>
yes, that would be great --
On Wed, Mar 18, 2015 at 8:43 AM, Paul Moore wrote:
> > I suppose it's too late now, but the really painful parts of all this
> > seem to be due to overly aggressive backward compatibility. We now
> > have wheels, but also eggs, we now have pip, but also easy_install,
> > etc.
>
> Agreed. But the
.py that uses setuptools will have the
> --single-version-externally-managed option available.
>
yup -- so I need to tack that on when needed, and can't just do it for all
python packages...
Thanks -- that does make things a bit more clear!
-CHB
>
> Thanks,
> -- Ionel Cris
On Thu, Mar 19, 2015 at 9:56 AM, Chris Barker wrote:
> On Thu, Mar 19, 2015 at 9:26 AM, Ionel Cristian Mărieș > wrote:
>
>> The --record is for making a list of installed files. You don't need it
>> if you don't use record.txt anywhere.
>>
>
> thanks -
lds the package in order to then extract the dependency meta-data -- it
would be nice to not do that.
It actually succeeds with a lot of packages without any hand-editing after
the fact, to it's not so bad!
> As Chris Barker notes, --single-version-externally-managed is a good way
>
On Mon, Mar 23, 2015 at 11:45 AM, Dan Stromberg wrote:
> Is this the general perspective on static linking of python module
> dependencies? That if your systems are the same, you don't need to?
>
That's general -- nothing specific to python here.
There _may_ be a difference in that you might b
NOTE: I don't work for any of the companies involved -- just a somewhat
frustrated user... And someone that has been trying for years to make
things easier for OS-X users.
I’m not sure what (3) means exactly. What is a “normal” Python, do you
>> modify Python in a way that breaks the ABI but which
On Mon, Apr 13, 2015 at 1:19 PM, David Cournapeau
wrote:
> This is what we use on top of setuptools egg:
>
> - ability to add dependencies which are not python packages (I think most
> of it is already handled in metadata 2.0/PEP 426, but I would have to
> re-read the PEP carefully).
> - abilit
On Tue, Apr 14, 2015 at 8:41 AM, Nick Coghlan wrote:
> The main two language independent solutions I've identified for this
> general "user level package management" problem in the Fedora
> Environments & Stacks context
> (
> https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackage
>
> If there’s a plugin that understands this extension
> > installed, let it do something before you actually move the files into
> > place”. This let’s Wheels themselves still be declarative and moves the
> > responsibility of implementing these bits into their own PyPI projects
> > that can be v
On Tue, Apr 14, 2015 at 9:46 AM, Paul Moore wrote:
> > Could an "extension" be -- "run this arbitrary Python script" ?
>
> The main point (as I see it) of an "extension" is that it's
> distributed independently of the packages that use it. So you get to
> decide to use an extension (and by infere
On Tue, Apr 14, 2015 at 8:57 PM, Kevin Horn wrote:
> Personally, I'm not a fan of auto-installing,
>
>
> I'm with Paul on this one. It seems to me that auto-installing the
> extension would destroy most of the advantages of distributing the
> extensions separately.
>
Exactly -- I actually toss
On Wed, Apr 15, 2015 at 2:23 PM, Paul Moore wrote:
> In the PEP, there's a concept of "optional" vs "required" extensions.
> See https://www.python.org/dev/peps/pep-0426/#required-extension-handling.
> This is crucial - I've no problem if a particular extension is used by
> a project, as long as
A note from the peanut gallery:
I like the idea of namepace packages, but every time I've tried to use
them, I've been stymied -- maybe this PEP will solve that, but...
First - the issues:
- It somehow seems like a lot of work, details to get right, and
more-than-one-way-to-do-it. But maybe th
On Wed, Apr 22, 2015 at 5:31 PM, Donald Stufft wrote:
> This seems SO SIMPLE.
>
> ...
> What am I missing?
>
> Prior to PEP 420 you needed the dynamic path stuff because sometimes your
> namespace package is split across multiple locations on sys.path.
>
OK -- sure you'd need it then -- still n
>
> >> I'm confused -- you don't want a system to be able to install ONE
> version
> >> of a lib that various python packages can all link to? That's really the
> >> key use-case for me
>
> Are we talking about Python libraries accessed via Python APIs, or
> linking to external dependencies n
On Thu, May 14, 2015 at 4:41 PM, Robert Collins
wrote:
> > anyway) you now have three copies of the same lib (but maybe different
> > versions) all linked into your executable. Maybe there is no downside to
> > that (I haven't had a problem yet), but it seems like a bad way to do it!
>
> If they
On Fri, May 15, 2015 at 1:49 AM, Paul Moore wrote:
> On 14 May 2015 at 19:01, Chris Barker wrote:
> > Ah -- here is the issue -- but I think we HAVE pretty much got what we
> need
> > here -- at least for Windows and OS-X. It depends what you mean by
> > "cur
On Fri, May 15, 2015 at 1:44 PM, Paul Moore wrote:
> > Is there any point? or is the current approach of statically linking all
> > third party libs the way to go?
>
> If someone can make it work, that would be good. But (a) nobody is
> actually offering to develop and maintain such a solution,
On Fri, May 15, 2015 at 11:35 PM, David Cournapeau
wrote:
> On Sat, May 16, 2015 at 4:56 AM, Chris Barker
> wrote:
>
>>
>> But in short -- I'm pretty sure there is a way, on all systems, to have a
>> standard way to build extension modules, combined with a standa
On Sat, May 16, 2015 at 4:13 AM, Paul Moore wrote:
> > Though it's a lot harder to provide a build environment than just the
> lib to
> > link too .. I"m going to have to think more about that...
>
> It seems to me that the end user doesn't really have a problem here
> ("pip install matplotlib" w
On Sat, May 16, 2015 at 11:54 AM, Paul Moore wrote:
> > could you clarify a bit -- I thought that this could, at least, put a
> dir on
> > the search path that was specific to that python context. So it would
> > require cooperation among all the packages being used at once, but not
> get
> > tan
On Sat, May 16, 2015 at 10:12 AM, Nick Coghlan wrote:
> > Maybe, but it's a problem to be solved, and the Linux distros more or
> less
> > solve it for us, but OS-X and Windows have no such system built in (OS-X
> > does have Brew and macports)
>
> Windows 10 has Chocalatey and OneGet:
>
> *
On Sat, May 16, 2015 at 12:04 PM, David Mertz wrote:
> Continuum has a great desire to make 'pip' work with conda packages.
> Obviously, we love for users to choose the Anaconda Python distribution but
> many will not for a variety of reasons (many good reasons).
>
Hmm -- this strikes me as very
On Sat, May 16, 2015 at 3:03 PM, Donald Stufft wrote:
> There are a few other benefits, but that’s not anything that are inherent
> in the two different approaches, it’s just things that conda has that pip
> is planning on getting,
>
Huh? I"'m confused -- didn't we just have a big thread about h
On Sat, May 16, 2015 at 4:16 PM, Donald Stufft wrote:
> On Sat, May 16, 2015 at 3:03 PM, Donald Stufft wrote:
>
>> There are a few other benefits, but that’s not anything that are inherent
>> in the two different approaches, it’s just things that conda has that pip
>> is planning on getting,
>>
On Sun, May 17, 2015 at 12:05 AM, Nick Coghlan wrote:
> > % pip install --upgrade pip
> > % pip install some_conda_package
>
> This gets the respective role of the two tools reversed - it's like my
> asking for "pip install some_fedora_rpm" to be made to work.
>
I agree here -- I was thinkin
Trying to keep this brief, because the odds of my finding time to do much
with this are slim..
> I'm not proposing that we drop it -- just that we push pip and wheel a
bit farther to broaden the supported user-base.
> I can't stop you working on something I consider a deep rabbithole,
>
no -- but
On Sun, May 17, 2015 at 5:12 PM, Robert Collins
wrote:
> > > But I'm confused as to the roles of pip vs setuptools, vs wheel, vs ???
> > >
> > > I see pip has handling the dependency resolution, and finding and
> downloading of packages part of the problem -- conda does those already.
> > >
> > >
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
On Tue, May 19, 2015 at 4:27 AM, Oscar Benjamin
wrote:
> Surely the best way to manage non-Python shared libs is by
> exposing them as extension modules which can be packaged up on PyPI.
> Then you have dependency resolution for pip, you don't need to worry
> about the OS-specific shared library
On Mon, May 18, 2015 at 8:24 PM, Vincent Povirk
wrote:
> > But maybe all you really need to do is teach conda to understand pip
> > meta-data, and/or make sure that conda write pip-compatible meta data.
>
> Forgive me, I'm trying to follow as someone who is working with PyPI
> but hasn't really u
On Tue, May 19, 2015 at 5:21 AM, Paul Moore wrote:
> If conda did everything pip did (and that includes consuming wheels
> from PyPI, not just sdists, and it includes caching of downloads,
> autobuilding of wheels etc, etc.)
hmm...what about half-way -- conda does everything pip does, but not
n
On Tue, May 19, 2015 at 9:15 AM, David Cournapeau
wrote:
> Honestly, I still haven't seen a solid explanation of why (at least on
>> Windows) static linking isn't a viable option.
>
>
well - it does get us pretty far
> Because some libraries simply don't work as static libraries, or are too
On Tue, May 19, 2015 at 11:10 AM, Paul Moore wrote:
> > to be the same. I suppose I could deliver the static libs themselves,
> along
> > with the headers, etc, but that does get ugly.
>
> Hmm, that seems to me to be something of a non-goal. If you publish
> wheels, 99.999% of people should never
On Tue, May 19, 2015 at 10:18 AM, Leonardo Rochael Almeida <
leoroch...@gmail.com> wrote:
> What if instead of focusing on pip being able to install more than just
> python packages, we made sure that a virtualenv was as strict subset of,
> say, a conda environment? This way, going from virtualenv
On Tue, May 19, 2015 at 10:58 AM, Paul Moore wrote:
> Sure. Doesn't have to be the same way, but the user experience has to
> be the same.
absolutely.
> But maybe that's not going to cut it -- in a way, we are headed there now,
> > with a contingent of people porting pypi packages to conda. S
On Tue, May 19, 2015 at 1:27 PM, Paul Moore wrote:
> > And maybe all that needs to be is a gitHub project with build scripts.
> But I
> > had little luck in getting any traction that way. That is, until we had
> > Anaconda, conda and binstar --- an infrastructure that provides a way
> for
> > fo
On Tue, May 19, 2015 at 1:19 PM, Wes Turner wrote:
> So it might make sense to actually allow folks to push conda to budding
>> web developers, if conda allowed installation (and environment management)
>> of sdist packages on PyPI. So perhaps it would be good if *this* worked:
>>
>> % pip ins
lost track of where in the thred this was, but here's a conda recipe I
found on gitHub:
https://github.com/menpo/conda-recipes/tree/master/libxml2
don't know anything about it.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 5
On Tue, May 19, 2015 at 3:04 PM, Paul Moore wrote:
> Yeah, I'm trying to never build anything for myself, just consume
> binaries. Having all binaries built by "the conda people" is a
> bottleneck.
it is -- though the group of "conda people" is growing...
> Having pip auto-build wheels once
On Tue, May 19, 2015 at 3:09 PM, Paul Moore wrote:
> So, for example the process for building the pyyaml package available
> via conda is private?
well, I haven't been able to find them... I don't know if continuum keeps
them "private" on purpose or, just haven't happened to publish them.
>
On Wed, May 20, 2015 at 1:04 AM, Paul Moore wrote:
> > https://github.com/menpo/conda-recipes/tree/master/libxml2
> >
> > don't know anything about it.
>
> OK, I'm still misunderstanding something, I think. As far as I can
> see, all that does is copy a published binary and repack it. There's
On Tue, May 19, 2015 at 4:12 PM, salil GK wrote:
> I will provide more details about what I need to achieve
>
> I need to create a package for a tool that I create. Actually the tool
> that I created is a wrapper over ovftool which is provided by VMWare.
> ovftool install binary is provided as
On Wed, May 20, 2015 at 6:30 AM, Daniel Holth wrote:
> The package includes its build recipe in info/recipe
>
very cool -- I hadn't seen that -- I'll go take a look at some packages and
see what I can find.
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS
>
> The package includes its build recipe in info/recipe
>>
>
> very cool -- I hadn't seen that -- I'll go take a look at some packages
> and see what I can find.
>
Darn -- the recipe is not there in most (all?) of the packages that came
from Anaconda -- probably due to the legacy issues David ref
On Wed, May 20, 2015 at 12:57 AM, Nick Coghlan wrote:
> This is why I'm such a big fan of richer upstream metadata with
> automated conversion to downstream formats as my preferred long term
> solution - this isn't a "pip vs conda" story, it's "pip vs conda vs
> yum vs apt vs MSI vs nix vs zypper
On Wed, May 20, 2015 at 5:20 PM, Nick Coghlan wrote:
> Coping with this problem is also why injecting setuptools when running
> vanilla distutils projects is one of the secrets of pip's success:
Ahh! THAT is the role pip plays in building. It's the way that you get
setuptools features in a plai
On Wed, May 20, 2015 at 3:46 PM, Nick Coghlan wrote:
> On 21 May 2015 at 03:37, Chris Barker wrote:
> > As such, it _could_ play the role that pip+wheel (secondarily pypi) play
> in
> > the python ecosystem.
>
> In practice, it can't, as conda is entirely inappropr
On Wed, May 20, 2015 at 5:43 PM, Nick Coghlan wrote:
> One of my hopes for the metadata extension system in PEP 426 is that
> we'll be able to define extensions like "fedora.repackage",
> "debian.repackage" or "conda.repackage" which include whatever
> additional info is needed to automate creat
On Thu, May 21, 2015 at 11:12 AM, Jonathan Helmus
wrote:
> it sounds like a tool that is capable of converting between conda
> packages and wheel files
converting from a wheel to a conda package should be very doable (and may
already be done). But the other way around is not -- conda packages
On Thu, May 21, 2015 at 1:12 PM, Paul Moore wrote:
> > built from wheel right now, with no special tools. A conda recipe that
> > simply installs a wheel in it's build script would do just that.
>
> That sounds about right, from what I've seen of conda builds. You
> could probably do better (for
On Fri, May 29, 2015 at 7:23 AM, Paul Sokolovsky wrote:
> > An example of a product that does this is Chef, they install their
> > own Ruby and everything but libc into /opt/chef to completely isolate
> > themselves from the host system.
this sounds a bit like what conda does -- install minico
TL;DR -- pip+wheel needs to address the non-python dependency issue before
it can be a full solution for Linux (or anything else, really)
The long version:
I think Linux wheel support is almost useless unless the pypa stack
provides _something_ to handle non-python dependencies.
1) Pure Python p
On Fri, Jul 17, 2015 at 8:46 AM, Antoine Pitrou wrote:
> Due to the fact Linux binary wheels don't exist, conda is even more
> useful on Linux...
>
True -- though it's at least possible, and certainly easier than on Mac and
Windows, to build it all yourself on Linux.
-CHB
--
Christopher Ba
On Sun, Jul 19, 2015 at 10:50 PM, Nick Coghlan wrote:
> The intended use case is "Build once, deploy many times".
>
> This is especially important for use cases like Nate's - Galaxy has
> complete control over both the build environment and the deployment
> environment, but they *don't* want to r
On Sun, Jul 19, 2015 at 11:00 PM, Nick Coghlan wrote:
> However, Nate has a specific concrete problem in needing to get
> artifacts from Galaxy's build servers and installing them into their
> analysis environments - let's help him solve that, on the assumption
> that some *other* mechanism will
On Tue, Jul 21, 2015 at 9:38 AM, Oscar Benjamin
wrote:
>
> I think it would be great to just package these up as wheels and put them
> on PyPI.
>
that's the point -- there is no way with the current spec to specify a
wheel dependency as opposed to a package dependency. i.e this particular
binary
On Thu, Aug 6, 2015 at 9:05 AM, Rachel Krabacher wrote:
> My name is Rachel and I am a master's student using Python as part of my
> thesis work analysis. I have found a package online and have downloaded it
> from github, but am having difficulties getting Python to recognize that I
> have down
On Wed, Aug 12, 2015 at 6:05 PM, Nathaniel Smith wrote:
> (2) the special hard-coded tag "centos5". (That's what everyone actually
> uses in practice, right?)
>
Is LSB a fantasy that never happened? I haven't followed it for years
-CHB
> Compare with osx, where there are actually a ton of d
On Thu, Aug 13, 2015 at 10:52 AM, David Cournapeau
wrote:
> So this is a basic list I got w/ a few minutes of scripting,
>
could we define this list (or somethign like it) as
"Python-Linux-Standard-Base-version X.Y"
Then we have a tag to use on binary wheels, and clearly defined way to know
whe
On Fri, Aug 14, 2015 at 9:17 AM, Steve Dower wrote:
> I actually like two ideas for Windows (not clear to me how well they apply
> on other platforms),
I think this same approach should be used for OS-X, not sure about Linux --
on LInux, you normally have "normal" ways to get libs.
both of whi
On Mon, Sep 28, 2015 at 11:19 AM, Matthew Iversen
wrote:
> For example, the two are different for flask, virtualenv, setuptools,
> sopel, numpy
>
these are some pretty significant, complex packages.
I have trouble finding an objective reasoning that one method is to be
> objectively preferred o
I'm not sure if I understand what Nathaniel is getting at, but...
> As the very simplest example, every package that uses the numpy C API
> > gets a runtime dependency on "numpy >= [whatever version happened to
> > be installed on the *build* machine]".
> From my point of view, it's not a sourc
I can't seem to find a way to pip install from a source dir -- not a
tarball.
Why would I want to do that?
In this case, it's because I'm trying to build conda packages for python
packages that have compiled C code, and are not using setuptools.
On Windows, you need to use setuptools in order to
B
> On October 2, 2015 at 5:38:29 PM, Chris Barker (chris.bar...@noaa.gov)
> wrote:
> > I can't seem to find a way to pip install from a source dir -- not a
> > tarball.
> >
> > Why would I want to do that?
> >
> > In this case, it's becaus
On Fri, Oct 2, 2015 at 2:45 PM, Nathaniel Smith wrote:
> > I would rather see an sdist format that can be introspected *without*
> > running code or a build tool.
indeed -- this has come up a lot on this list, for binary dists, too, of
course.
but "build script as turing complete" [someone po
ent build environment -- this will
assure it used the right pip.
Thanks all, this is working great.
-CHB
> Erik
>
> > On October 2, 2015 at 5:38:29 PM, Chris Barker (chris.bar...@noaa.gov)
> wrote:
> >> I can't seem to find a way to pip install from a source dir --
On Tue, Oct 6, 2015 at 10:38 PM, Thomas Güttler <
guettl...@thomas-guettler.de> wrote:
> Yes, there is not generic "one right way here".
>
> Yes, let's consider individual use cases.
>
> My use case are the docs for new comers:
>
> - https://github.com/pypa/sampleproject
> - https://packaging.py
How many people can join a hangout? we may be bumping up against that limit
:-)
-CHB
On Thu, Oct 8, 2015 at 12:58 PM, Nathaniel Smith wrote:
> On Oct 8, 2015 09:33, "Nathaniel Smith" wrote:
> >
> > On Oct 8, 2015 8:14 AM, "Nathaniel Smith" wrote:
> > >
> > > On Oct 7, 2015 2:58 PM, "Donald St
I"ve been following this thread and gotten a bit lost. But I do care,
because I'm a heavy numpy user, and also because I was involved for years
in building pacakges for OS-X, and currently need distribute some of my own
stuff that has semi-ugly C lib dependencies (Not as ugly as BLAS.,though
:-) )
On Fri, Oct 9, 2015 at 10:44 AM, Thomas Güttler <
guettl...@thomas-guettler.de> wrote:
> The question remains: If a new comer asks you "How to package my
> python code and its tests?", there should be one default answer
> which works for 80% of all cases.
>
Should be, maybe -- but clearly there i
On Fri, Oct 9, 2015 at 10:28 AM, Paul Moore wrote:
> ... or thinking again, maybe you mean having multiple packages
> (numpy_mkl, numpy_openblas, ...) all of which satisfy a "numpy"
> requirement?
yes, that is EXACTLY what I meant.
the idea here is that if you build a package that requires bot
On Fri, Oct 9, 2015 at 11:28 AM, Oscar Benjamin
wrote:
> Why would it need dynamic metadata for the windows matplotlib wheel to
> have different metadata from the OSX matplotlib wheel? The platform
> Windows/OSX is static and each wheel declares its own dependencies
> statically but differently.
On Fri, Oct 9, 2015 at 11:44 AM, Oscar Benjamin
wrote:
> Assuming it's tied to the operating system it doesn't matter surely. When
> pip runs on Windows it can ignore dependencies that apply to other
> platforms so I don't see how this case makes it more complex.
>
does pip currently support plat
On Sun, Oct 11, 2015 at 11:18 AM, Steve Dower
wrote:
> And it's also not binding on redistributors or package builders, who are
> free to add more restrictive requirements.
>
not binding, but presumably a simple:
setup.py build
with distutils (or setuptools) will NOT use SSE2 in this case? Th
On Wed, Oct 14, 2015 at 3:40 AM, Antoine Pitrou wrote:
> On Tue, 13 Oct 2015 09:59:05 -0700
> Chris Barker wrote:
> >
> > So even is SSE2 provides little for Python itself, in the usual case,
> we'll
> > see performance hits n compiled extensions that are not co
Hi all,
PyPi does not allow duplicate file names -- this makes lots of sense,
because you really don't want people to go to PyPi one day and grab a file,
and then go there another day, grab a file with exactly the same name, and
have it be a different file.
However
We are all too human, and
On Wed, Oct 14, 2015 at 9:54 AM, Antoine Pitrou wrote:
> > IS that the case:
> > """
> > Note that my recently retired computer was 64 bit and had SSE but didn't
> > have SSE2 (I'm fairly sure - CPU was some budget AMD model)
> > """
> >
> > granted, such machines are probably really really rare,
On Wed, Oct 14, 2015 at 9:56 AM, Dave Forgac
wrote:
> This was discussed recently here:
> https://github.com/pypa/packaging-problems/issues/74
>
and on this list at other times. Though the above issue was pretty focused
on restoring a deleted file without any changes -- which seems like a
no-bra
On Wed, Oct 14, 2015 at 1:16 PM, Oscar Benjamin
wrote:
> Numpy's Windows installer bundles several BLAS binaries with different
> levels of SSE and this was the initial reason for not providing Windows
> wheels.
>
indeed -- but IIRC, SSE2 made a pretty big difference, but SSE3 not so much
-- thou
On Wed, Oct 14, 2015 at 1:04 PM, Donald Stufft wrote:
> > And it just seems pedantic to say: hey -- you've already put that one
> there
> > -- maybe even two minutes ago, so there is NO WAY to fix your mistake. If
> > it happens quickly, then no one has downloaded it, it hasn't made its way
> > t
On Wed, Oct 14, 2015 at 1:20 PM, Ionel Cristian Mărieș
wrote:
> This reminds me of Gmail's "unsend" feature where email would be delayed
> 10 seconds or something, giving a window to press the unsend button.
>
FWIW, I am a big fan of that -- and use it with remarkably frequency. --
maybe I'm j
On Wed, Oct 14, 2015 at 1:59 PM, David Cournapeau
wrote:
> But I'm talking about the cases of "whoops! I really wish I hadn't
>> uploaded that one". We can improve the tooling (some discussion on this in
>> this thread right now...), but people are people and some of us are stupid
>> and/or carel
On Wed, Oct 14, 2015 at 3:26 PM, Donald Stufft wrote:
> On October 14, 2015 at 6:24:55 PM, Chris Barker (chris.bar...@noaa.gov)
> wrote:
> > > another note-- conda has teh concetp of a "build" that's tacked
> > on teh release for conda pacakges.
> >
&
On Wed, Oct 21, 2015 at 9:34 AM, Thomas Güttler <
guettl...@thomas-guettler.de> wrote:
> I ask myself: Why a standard? I see that a standard is very important if
> there will be
> several implementations (for example TCP/IP, protocols like HTTP, SMTP,
> IMAP, ...)
>
> But here a single implementat
This is kind-of related to the othe thread:
"Remove distutils, was: ..."
But more specific, so I thought I'd start a new one.
Here are my thoughts:
We had distutils -- there was a lot it didn't do that the "Masses" needed,
so setuptools was born. It proved to be useful to a lot of people, and g
On Wed, Oct 21, 2015 at 10:03 AM, Ronny Pfannschmidt <
opensou...@ronnypfannschmidt.de> wrote:
> why does that have to be in setuptools ?!
>
it doesn't have to be in setuptools at all -- I suppose I should have
defined more clearly what I meant:
setuptools_lite would be a package that does all t
On Wed, Oct 21, 2015 at 10:17 AM, Paul Moore wrote:
> On 21 October 2015 at 17:42, Chris Barker wrote:
> > So why not have a setuptools-lite that only does the building?
> In general, this sounds like a reasonable idea. But, there are the
> usual problems:
>
> 1. Someone
On Wed, Oct 21, 2015 at 12:26 PM, Donald Stufft wrote:
> On October 21, 2015 at 3:13:11 PM, Chris Barker (chris.bar...@noaa.gov)
> wrote:
> >
> > replace all your "import setuptools" with "import setuptool_lite" would
> be
> > clear what the int
>
> > "some subset of what setuptools provides"
> >
> > So my proposal is here is to provide a way for users to easily use jsut
> that
> > subset.
>
> https://pip.pypa.io/en/stable/reference/pip_install/#build-system-interface
note above: *easily* use just that subset.
All you need to do is writ
On Wed, Oct 21, 2015 at 2:53 PM, Paul Moore wrote:
> As I've already said, we have a plan for that, it's
> just happening slowly (apparently too slowly for some people, but
> rather than helping with it they seem happier to propose alternative
> approaches that we've typically considered in the
On Wed, Oct 21, 2015 at 4:52 PM, Robert Collins
wrote:
> > Hmm, now that I think about it, maybe I can just banish setuptools from
> my
> > setup.py, stick with distutils, and then make sure to use pip to actually
> > invoke anything -- so it will inject setuptools, but only use the bits we
> > n
On Wed, Oct 21, 2015 at 7:27 PM, Robert Collins
wrote:
> > I guess I wasn't clear -- the idea was to force myself to use pip
> install,
> > rather than ever doing a plain
> >
> > setup.py install or
> > setup.py develop
> >
> > so:
> > pip install ./
> > or
> > pip install -e ./
> >
> > this wa
1 - 100 of 361 matches
Mail list logo
