[Distutils] How to handle launcher script importability?

[Donald Stufft]

On Aug 21, 2013, at 4:23 AM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:

> Donald Stufft <donald <at> stufft.io> writes:
> 
>> However what I don't really want is to be using someones personal testbed
>> for features they think is cool. There's nothing *wrong* with you trying
>> new ideas out in distlib, it just means that distib isn't the library I
>> want to build tooling around.
> 
> "Someone's personal test-bed"? How do you think all open source software
> starts out? What innovation isn't based on a feature someone thinks "is cool"?
> 
> From our interactions, I don't get a feeling that you're particularly
> interested in building tooling around distlib anyway, for reasons best known
> to you. This specific feature could be easily pulled, and distlib is still
> only at version 0.1.2. Nick has indicated he doesn't think it's appropriate
> to consider distlib ready for endorsement in a 3.4 time-frame, so there's
> plenty of time to make changes which are deemed necessary. How on earth do
> you expect people to try things out, see where the problems are and fix
> them, if you don't release such features? It would certainly help if you
> describe specific problems with this feature, rather than just "I don't like
> it".

I don't particularly care about this feature. I care about having a simple reference
library. That is what I thought distlib was supposed to be (and I'm not alone).
However if you want to innovate and experiment inside it then great, that's
fine. I just won't tell people that distlib is the reference library.

> 
>> My basic problem is if the library we're pointing at to be the reference
>> implementation of all of these things is adding new features it's
>> confusing what is standard and what are just distlib's extensions.
> 
> There are already features in distlib which aren't mentioned in any PEP -
> e.g. the ability to calculate dependency graphs without downloading any
> archives, or the ability to install scripts as single executables on
> Windows, or the ability to give better feedback when uninstalling.

As mentioned above, I'm not trying to argue against this particular feature
I'm just trying to make sure we have a simple reference library for
people to be pointed at.

> 
>> So basically I want people to innovate, that's something I feel very
>> strongly is a good thing, I just don't want innovations to happen in the
>> reference library. Maybe we need a smaller reference library which is
> 
> ISTM distlib is not yet that reference library - it's just another library
> for most people, judging from the low level of feedback I've had overall.

That's totally fine. We just need to be clear that it's not the reference
library and is instead one implementation.

> 
> There's plenty of time to try things out and make changes, so I find your
> approach a bit of an over-reaction, and feel that it doesn't square with
> what you're saying about innovation. You know that feeling you mentioned
> that you get, where you think everyone is just out to block you and stop you
> getting stuff done? Are you trying to spread that feeling around? ;-)

I think the way you view distlib and the way other are viewing distlib are
different (and that's ok). We just need to know what distlib is so we can
have reasonable expectations of it. What i'm getting from you is that, at
least right now, distlib isn't what I thought it was and I (and others) should
stop treating it as *the* reference implementation of the new standards.

I'm not trying to stop you from innovating, I'm just trying to make sure everyone
has reasonable expectations all around.

> 
> Regards,
> 
> Vinay Sajip
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130821/de446271/attachment-0001.sig>