I'd love for at least some IRC chatter or notes as I can't make it to pycon
this year.
Particularly if there is activity during the sprints on this stuff so I can
contribute from home
Paul
On 28 February 2013 18:00, Paul Moore wrote:
> On 28 February 2013 03:54, Nick Coghlan wrote:
> > It's
On 28 February 2013 03:54, Nick Coghlan wrote:
> It's only a couple of hours, because my aim is mostly to encourage
> information sharing through lightning talks about some of the key
> projects involved in packaging and distribution, rather than making
> any actual firm decisions about anything.
Paul Moore gmail.com> writes:
> distribute for the setup.py run? I've tried setting PYTHONPATH, but
> that doesn't seem to work
Here's what I tried. I set up the following work area:
.
├── pkg_resources.py -> /path/to/distribute/pkg_resources.py
├── runit.py
├── setuptools -> /path/to/distribut
OK, thanks!
On Feb 27, 2013, at 10:54 PM, Nick Coghlan wrote:
> On Thu, Feb 28, 2013 at 12:32 AM, Doug Hellmann
> wrote:
>> The Packaging Summit page [1] lists "Friday evening" but doesn't specify a
>> time or location, as far as I can tell. Have those been set, yet?
>>
>> Doug
>>
>> [1]
>>
On 28 February 2013 20:53, Daniel Holth wrote:
>> Sorry, I wasn't clear. I know about that, but I don't know how to set
>> up a site directory *before* starting the Python process. Thinking
>> about it, I guess I could do the addsitedir thing and then execfile
>> setup.py. Put all of that into a -
> Sorry, I wasn't clear. I know about that, but I don't know how to set
> up a site directory *before* starting the Python process. Thinking
> about it, I guess I could do the addsitedir thing and then execfile
> setup.py. Put all of that into a -c script. That's probably OK, just a
> bit messy. Pa
On 28 February 2013 20:30, Daniel Holth wrote:
> On Thu, Feb 28, 2013 at 3:26 PM, Paul Moore wrote:
>> For some scripts I am writing, I want to be able to run a package's
>> setup.py using subprocess.check_call(). However, the python
>> installation I'm using may not have setuptools/distribute in
On Thu, Feb 28, 2013 at 3:26 PM, Paul Moore wrote:
> For some scripts I am writing, I want to be able to run a package's
> setup.py using subprocess.check_call(). However, the python
> installation I'm using may not have setuptools/distribute installed,
> and yet I want to correctly process setup.
For some scripts I am writing, I want to be able to run a package's
setup.py using subprocess.check_call(). However, the python
installation I'm using may not have setuptools/distribute installed,
and yet I want to correctly process setup.py files which rely on
setuptools. Is there any way of setti
Paul Moore gmail.com> writes:
> I'm confused here, because you're mixing up tags. I agree that the ABI
> tag would have to be different. But cpXY is the *python* tag. Are you
> saying that extensions for Python compiled with a different MSVCRT
> should be considered as for a different implementat
On Thu, Feb 28, 2013 at 1:23 PM, PJ Eby wrote:
> Indeed. I'm hoping that the new tools will make the old ones (e.g.
> setuptools) entirely irrelevant, which is why I'm hammering so hard in
> the PEP discussions on some use cases that eggs do well that wheels
> don't. I don't want people to have
yes, to what Reinout said.
also, I thought this post from one of your threads was good
http://lists.openstack.org/pipermail/openstack-dev/2013-February/006103.html
if you want repeatable installs and testing throughout your release cycle,
you have to pin your whole dependency tree.
but in order
On 28-02-13 16:39, Mark McLoughlin wrote:
Generally speaking, when a project has a large list of dependencies on
libraries outside of its control, it can take one of two approaches to
those dependencies:
1) specify the minimum required version of each library and assume new
releases of al
On Thursday, February 28, 2013 at 10:39 AM, Mark McLoughlin wrote:
> Hey,
>
> (I sent this to the wrong list and was directed here by Nick. I wasn't
> aware of the very promising sounding PEP426 and haven't read it yet, so
> apologies on that. Just wanted to resend my mail here ASAP to prevent
> t
On Thu, Feb 28, 2013 at 10:39 AM, Mark McLoughlin wrote:
> Hey,
>
> (I sent this to the wrong list and was directed here by Nick. I wasn't
> aware of the very promising sounding PEP426 and haven't read it yet, so
> apologies on that. Just wanted to resend my mail here ASAP to prevent
> the discuss
Hey,
(I sent this to the wrong list and was directed here by Nick. I wasn't
aware of the very promising sounding PEP426 and haven't read it yet, so
apologies on that. Just wanted to resend my mail here ASAP to prevent
the discussion happening on the wrong list. Thanks!)
Generally speaking, when a
>> OK, we don't generate anything like that for Windows at the moment,
>> then (where ABI is always "none").
>
> "none" means "this wheel has no dependency on the ABI at all". If a
> wheel includes C extensions and also has the ABI tag set to none, the
> tool creating those wheels is broken (althou
On Thu, Feb 28, 2013 at 10:04 AM, Nick Coghlan wrote:
> On Fri, Mar 1, 2013 at 12:00 AM, Daniel Holth wrote:
>> We will probably wind up with some JSON very much like that. I like
>> just exposing it as an ordered multidict with the same key names as
>> mentioned in the PEP.
>
> A multidict is no
On Fri, Mar 1, 2013 at 12:00 AM, Daniel Holth wrote:
> We will probably wind up with some JSON very much like that. I like
> just exposing it as an ordered multidict with the same key names as
> mentioned in the PEP.
A multidict is not really JSON-compatible - making sure there's an
unambiguous m
On Thu, Feb 28, 2013 at 11:52 PM, Paul Moore wrote:
> On 28 February 2013 13:36, Daniel Holth wrote:
>> On Thu, Feb 28, 2013 at 4:02 AM, Paul Moore wrote:
>>> On 28 February 2013 06:07, Nick Coghlan wrote:
On Thu, Feb 28, 2013 at 5:47 AM, Paul Moore wrote:
> It's certainly true that t
On Thu, Feb 28, 2013 at 12:54 AM, Nick Coghlan wrote:
> On Thu, Feb 28, 2013 at 7:59 AM, Daniel Holth wrote:
>> My aim is to provide a hook mechanism that specifically does not say
>> anything about the way the cache is stored or even whether the hook
>> produces a cache at all. It will just run
On 28 February 2013 13:36, Daniel Holth wrote:
> On Thu, Feb 28, 2013 at 4:02 AM, Paul Moore wrote:
>> On 28 February 2013 06:07, Nick Coghlan wrote:
>>> On Thu, Feb 28, 2013 at 5:47 AM, Paul Moore wrote:
It's certainly true that the ABI flags are incomplete (there's also
the whole st
On Thu, Feb 28, 2013 at 4:02 AM, Paul Moore wrote:
> On 28 February 2013 06:07, Nick Coghlan wrote:
>> On Thu, Feb 28, 2013 at 5:47 AM, Paul Moore wrote:
>>> It's certainly true that the ABI flags are incomplete (there's also
>>> the whole stable ABI to consider).
>>
>> The stable ABI is covered
On 28 February 2013 06:07, Nick Coghlan wrote:
> On Thu, Feb 28, 2013 at 5:47 AM, Paul Moore wrote:
>> It's certainly true that the ABI flags are incomplete (there's also
>> the whole stable ABI to consider).
>
> The stable ABI is covered in PEP 425: the stable ABI compatibility tag
> is "abi3",
On 28 February 2013 00:46, Oscar Benjamin wrote:
> I apologise if I have misunderstood as I don't understand these things
> that well. But as someone who uses mingw on Windows (when I am on
> Windows) I have a question. What if I build with mingw on my computer
> and then upload to PyPI? Is it gua
25 matches
Mail list logo
