On 03/16/2015 02:53 PM, Daniel Holth wrote:
No one should be asked to learn how to extend distutils, and in
practice no one knows how.
People have been begging for years for working setup_requires, far
longer than I've been interested in it, and all they want to do is
import fetch_version
setup
Folks,
I'm having a hard time catching up with this, but maybe a few comments
from someone well outside the trenches will be helpful.
And note that one of use cases I'm now wrestling with is using another
package manager (conda), and setuptools is currently a PITA in that
context.
>> you that "p
Just a couple of comments
On 18 March 2015 at 15:33, Chris Barker - NOAA Federal
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
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 install- time task.
>
Sounds to me like you should not use setup_requires then - if you don't
like what it does.
On 18 March 2015 at 16:02, Ionel Cristian Mărieș wrote:
> one certainly doesn't need to shoehorn a full blown build system into
> setup.py - there's make, invoke, shell scripts and plenty of other systems
> that can do that just fine.
Just to insert a little history here, before distutils (setup.
On Wed, Mar 18, 2015 at 12:02 PM, Ionel Cristian Mărieș
wrote:
>
> On Wed, Mar 18, 2015 at 5:33 PM, Chris Barker - NOAA Federal
> wrote:
>>
>> I don't want it downloading and installing dependencies when I go to
>> build. That's an install- time task.
>
>
> Sounds to me like you should not use se
> On 18 Mar 2015, at 17:49, Paul Moore wrote:
>
> On 18 March 2015 at 16:02, Ionel Cristian Mărieș wrote:
>> one certainly doesn't need to shoehorn a full blown build system into
>> setup.py - there's make, invoke, shell scripts and plenty of other systems
>> that can do that just fine.
>
> Ju
It's been ~3 months or so since PEP 440 support was released in pip and
setuptools. I think at this point we've resolved any major issues with the
PEP 440 spec that can be resolved without a whole new PEP. In addition it's
now been out long enough that people have adjusted processes/tooling to acco
Chris McDonough writes:
> FWIW, this particular use case (retrieving the version by importing it
> or a function that returns it after it reads a file or whatever), is
> dodgy. It's way better that code that needs version info inside the
> package consult pkg_resources or some similar system:
>
>
For awhile now PyPI has supported JSONP on the /pypi/*/json API to allow people
to access the JSON data in a cross origin request. JSONP is problematic psuedo
standard which has niggly edge cases which make it hard to fully secure.
Browsers have a much better standard through CORS to handle this us
+1, JSONP was an interim hack solution way before CORS was an option.
On Thu, 19 Mar 2015 at 13:58 Donald Stufft wrote:
> For awhile now PyPI has supported JSONP on the /pypi/*/json API to allow
> people
> to access the JSON data in a cross origin request. JSONP is problematic
> psuedo
> standar
On 19 March 2015 at 08:11, Donald Stufft wrote:
> It's been ~3 months or so since PEP 440 support was released in pip and
> setuptools. I think at this point we've resolved any major issues with the
> PEP 440 spec that can be resolved without a whole new PEP. In addition it's
> now been out long e
On 19 March 2015 at 02:49, Paul Moore wrote:
> On 18 March 2015 at 16:02, Ionel Cristian Mărieș wrote:
>> one certainly doesn't need to shoehorn a full blown build system into
>> setup.py - there's make, invoke, shell scripts and plenty of other systems
>> that can do that just fine.
>
> Just to
13 matches
Mail list logo
