On Fri, Nov 6, 2015 at 12:33 PM, Ionel Cristian Mărieș
wrote:
> Why not consider having a "pip" launcher? Seems the obvious thing to me
> - python has the "py" launcher on windows and it works great!
>
> Eg: "pip -3" to launch pip using python3, "pip -3.5" to launch pip using
> python3.5 - just
On Tue, Dec 15, 2015 at 9:20 AM, Paul Moore wrote:
> This is more a thought for something that would be good to include in
> Metadata 2.0, or whatever ends up taking its place.
>
> I was installing some packages on a new PC, that doesn't have a
> compiler. As I did so, I noticed a dependency on s
On Tue, Dec 15, 2015 at 12:30 PM, Paul Moore wrote:
> I guess you're saying add [speedups] as a way of requesting a rebuild?
> But if the build fails, would that remove sqlalchemy, or leave the
> existing build there? (I'd hope the latter).
>
Well in this world of wheels we aren't necessarily bu
ber 2015 at 07:30, Paul Moore wrote:
> > On 15 December 2015 at 16:37, Michael Merickel
> wrote:
> >> It seems to me this would be easily accomplished by declaring some
> extras
> >> like "cext" as default-included and if the install fails someone can
> de
On Wed, Apr 27, 2016 at 2:18 PM, Daniel Holth wrote:
> To answer the original question, report the bug here
> https://bitbucket.org/pypa/wheel
>
It looksl ike there's already a similar bug opened at
https://bitbucket.org/pypa/wheel/issues/147/bdist_wheel-should-start-by-cleaning-up
I ran into t
On Fri, Jun 23, 2017 at 9:43 AM, Ben Finney
wrote:
> So, what is the period – when does it start and when does it end – that
> the Crossover state will active?
>
The time of officially recommending "pypi.org" was Sept 2017 when
setuptools v27 was released which switched the default.
https://set
I think it's far-fetched to start thinking pip is legacy. Pipfile has had a
goal from day 1 to be a format that pip would support. PEP 582 is a path
forward here for providing a default location for a virtualenv [2] - it's
just that everything moves slower in pip because it supports more use-cases
How about building a deprecation period into the tooling? pip 1.5+ could
warn users who are using *.pypi.python.org of the error in their ways and
encourage them to switch to the new system and gives a date of total
removal. After removal the code could also be removed from pip 1.x+.
- Michael
O
Yeah, setuptools is a bw-compat wrapper around distutils, so it tends to
only document its new features. This approach to documentation makes it
very difficult to understand for newcomers that are not familiar with
distutils. Especially now that setuptools is the de facto standard that
everyone is
See https://mail.python.org/pipermail/distutils-sig/2014-May/024167.htmlfor
more info. Sounds like bitbucket started rate limiting the content.
On Tue, May 6, 2014 at 4:09 PM, Chris Withers wrote:
> Hi All,
>
> Seeing lots of Jenkins jobs intermittently failing with this:
>
> Traceback (most rec
I don't normally like shameless plugs but I haven't seen many people use
docker in the following way yet and I happen to be using it with
zc.buildout.
I have built a small tool called marina[1] that I'm using to build binary
slugs that can be installed in production. It uses throwaway (clean-room)
I'm noticing a trend that depending on setuptools is discouraged[1] in
the install_requires of your setup.py. However, some packages like
pyramid have core features that depend on pkg_resources (which is part
of setuptools). Thus, we depend on it. As I've monitored distutils-sig
I haven't seen any
On Thu, Oct 23, 2014 at 3:50 PM, Donald Stufft wrote:
> As oh right now pkg_resources is part of setuptools, it’s only the downstream
> folks who split them apart. There are some decisions to make regarding
> splitting
> them out that I don’t know how setuptools wants to handle it.
>
> However on
On Tue, Jan 20, 2015 at 9:27 PM, Ben Finney wrote:
> Is there an API within Distutils or Setuptools that allows me to say “I
> haven't declared anything yet but go get and install distribution FOO
> right now”? I could do that before importing the module which needs
> Docutils.
What you're asking
At the pylons project we've had a history of keeping our tests inside the
packages. However, keeping them outside has proven to be nicer in some
projects as well. 1) It reduces the size of the binary wheels that do not
need to package the tests. 2) It still allows you to run the tests on an
arbitra
15 matches
Mail list logo
