On 17 April 2015 at 16:17, Brian Cole wrote:
> We've recently converted over to using bdist_wininst for creating our
> Windows .exe installers for our libraries. Unfortunately, whenever we use
> the Windows signtool utility to cryptographically sign our installer it
> appears to corrupt the .exe a
It may be possible to add an empty key container to the stub with signtool so
that it can be filled in after adding the zip without having to extend the
length. I believe the PE header is modified to locate the certificate, so it
doesn't necessarily have to be at the end.
Feel free to investiga
For the most part, I think it's all been said. What should and
shouldn't be installed by default is really specific extension
dependent, not much point in speculating.
But a comment or two:
having to type
> "python -m something" rather than just "something" isn't broken, it's
> just an inconve
According to this resource:
http://recon.cx/2012/schedule/attachments/54_Signed_executables.pps
it is doable, but tricky, and IIUC may not work on Windows XP SP2/SP3.
Wouldn't it be safer for the stub to work correctly in the presence of a
signature? Presumably it could use a different algorithm
On 18 April 2015 at 18:19, Chris Barker - NOAA Federal
wrote:
(your quote trimming's a bit over-enthusiastic, you lost the attribution here)
>> "python -m something" rather than just "something" isn't broken, it's
>> just an inconvenience.
>
> Tell that to a newbie. This is EXACTLY the kind of t
On 18 April 2015 at 18:27, Vinay Sajip wrote:
> Wouldn't it be safer for the stub to work correctly in the presence of a
> signature? Presumably it could use a different algorithm to locate the
> archive directory, rather than just expecting it to be at the end of the
> file.
It's the definition
The wheel installer does call setuptools to generate console script
wrappers.
On Apr 18, 2015 1:36 PM, "Paul Moore" wrote:
> On 18 April 2015 at 18:19, Chris Barker - NOAA Federal
> wrote:
>
> (your quote trimming's a bit over-enthusiastic, you lost the attribution
> here)
>
> >> "python -m some
On 17 April 2015 at 18:32, Donald Stufft wrote:
>
> Would Daniel’s change still require a PEP to make it or would it just
> require a PR? If we’re going to make a GitHub repository the source
> of truth for specs would it make sense to just ditch PEPs all together
> and use Pull Requests to handle
On 18 April 2015 at 13:36, Paul Moore wrote:
> On 18 April 2015 at 18:19, Chris Barker - NOAA Federal
> wrote:
>
> (your quote trimming's a bit over-enthusiastic, you lost the attribution here)
>
>>> "python -m something" rather than just "something" isn't broken, it's
>>> just an inconvenience.
On 18 April 2015 at 20:02, Nick Coghlan wrote:
>> It's a huge "quality of implementation" issue, certainly - any
>> installer that doesn't include script generation built in is going to
>> be as annoying as hell to a user. But they do exist (wheel install,
>> for instance) and the resulting instal
I am working on a minor update to the wheel format to add more
categories under which files can be installed. Constructive comments
welcome.
Distutills, setuptools, wheel currently have the best support for
installing files relative to ('purelib', 'platlib', 'headers',
'scripts', 'data') with 'dat
On 18 April 2015 at 22:24, Daniel Holth wrote:
> with 'data' usually meaning '/' or the root of the virtualenv
On Windows, it means sys.prefix.
In a user install, it means
- %APPDATA%\Python on Windows
- ~/Library/$PYTHONFRAMEWORK/x.y on Darwin (is that OSX?)
- ~/.local on Unix
See sysconfig.p
On Sat, Apr 18, 2015 at 7:26 PM, Paul Moore wrote:
> On 18 April 2015 at 22:24, Daniel Holth wrote:
>> with 'data' usually meaning '/' or the root of the virtualenv
>
> On Windows, it means sys.prefix.
>
> In a user install, it means
>
> - %APPDATA%\Python on Windows
> - ~/Library/$PYTHONFRAMEWOR
On 18 April 2015 at 21:31, Daniel Holth wrote:
> On Sat, Apr 18, 2015 at 7:26 PM, Paul Moore wrote:
>> Examples of where this functionality is needed would be great. I'm
>> worried that we'll over-engineer a solution otherwise.
>
> Remember when distutils-sig didn't believe that Windows users act
14 matches
Mail list logo
