> Hmm, clicking the link in the email works here. but just to be safe:
>
> http://goo.gl/pC48e
>
Thanks - looks nice! What is the license which applies to the code? Is it
available in a public repository?
Regards,
Vinay Sajip
___
Python-Dev mailin
Paul Moore gmail.com> writes:
> Correct me if I'm wrong, but if we standardised on a particular
> structure, the hooks.py contents could actually be integrated into the
> core, if we wanted? People could still write hooks for more complex
> cases, but the basic binary build case could work out of
On 17 October 2011 10:15, Vinay Sajip wrote:
> It may not work for you, because in the default branch, packaging is currently
> missing some functionality or has bugs (I've raised about a dozen issues since
> trying to get packaging working with virtual environments).
Ah. That might be part of th
Paul Moore gmail.com> writes:
> Interesting. That's not a use case that I have encountered, but I can
> see it could be an issue. I have been working on the basis that a
> bdist_simple format that matches the functionality of bdist_wininst is
> at least good enough for those projects that current
On Sunday, October 16, 2011 02:24:58 PM Vinay Sajip wrote:
> Jeremy Kloth gmail.com> writes:
> > That said, I have been working on a drop-in replacement for the current
>
> > bdist_wininst executable stub with the following features:
> [snip]
>
> > http://www.flickr.com/photos/67460826 N04/se
On 16 October 2011 22:32, Vinay Sajip wrote:
> There's one area of pysetup3 functionality which I don't think has been
> discussed in this thread, though it's pertinent to Windows users. Namely, a
> completely declarative approach to installation locations will not satisfy all
> requirements. For
Paul Moore gmail.com> writes:
>
> On 13 October 2011 17:25, Éric Araujo netwok.org> wrote:
> >> My expectation would be that the user would type pysetup install
> >> some_binary_format_file.zip and have that file unpacked and all the
> >> "bits" put in the appropriate place. Basically just like
Éric Araujo netwok.org> writes:
> [Vinay]
> > A simple change to packaging will allow an archive containing a
> > setup.cfg-based > > directory to be installed in the same way as a
> > source directory.
> Isn’t that already supported, as long as the tarball or zipfile contains
> source files? In
Nick Coghlan gmail.com> writes:
> Compilation can be a problem on Linux systems as well, so a platform
> neutral format is a better idea. Just have a mechanism that allows
> pysetup to create a bdist_msi from a bdist_simple. Similar, bdist_rpm
> and bdist_deb plugins could be taught to interpret
Martin v. Löwis v.loewis.de> writes:
> In particular wrt. virtual environments: I see no need to actually
> *install* files multiple times. It's rather sufficient that the
> distributions to be installed are *available* in the virtual env after
> installation, and unavailable after being removed
Jeremy Kloth gmail.com> writes:
> That said, I have been working on a drop-in replacement for the current
> bdist_wininst executable stub with the following features:
[snip]
> http://www.flickr.com/photos/67460826 N04/sets/72157627653603530/
[snip]
Sounds interesting, but your flickr link di
On 13 October 2011 17:25, Éric Araujo wrote:
>> My expectation would be that the user would type pysetup install
>> some_binary_format_file.zip and have that file unpacked and all the
>> "bits" put in the appropriate place. Basically just like installing
>> from a source archive - pysetup install
On 15 October 2011 09:04, Nick Coghlan wrote:
> On Sat, Oct 15, 2011 at 4:42 AM, Paul Moore wrote:
>> I wish I felt more comfortable with MSI as a format (as opposed to an
>> opaque clickable installer). I'd be interested to know what others
>> think.
>
> Compilation can be a problem on Linux sys
On Sat, Oct 15, 2011 at 4:42 AM, Paul Moore wrote:
> I wish I felt more comfortable with MSI as a format (as opposed to an
> opaque clickable installer). I'd be interested to know what others
> think.
Compilation can be a problem on Linux systems as well, so a platform
neutral format is a better
On 14 October 2011 17:46, "Martin v. Löwis" wrote:
>
>> - On formats, I strongly believe that having multiple formats is a
>> problem. But I need to be clear here - an installer (MSI, wininst) is
>> a bundle containing executable code (which drives the interface), plus
>> a chunk of data that is t
- On formats, I strongly believe that having multiple formats is a
problem. But I need to be clear here - an installer (MSI, wininst) is
a bundle containing executable code (which drives the interface), plus
a chunk of data that is the objects to be installed. (I am
oversimplifying here, but bea
On 14 October 2011 15:13, "Martin v. Löwis" wrote:
>> Thanks for the clarification. I can see why this would be important.
>> But maintaining 3 different interfaces to do essentially the same
>> thing (collect some data from the user, then based on that data put
>> the same set of files in the sam
One other aspect is that MSI format is essentially opaque (correct me
if I'm wrong here).
You are wrong: msiexec /a unpacks an MSI extracts the files from the
MSI (documented as "administrative installation", meaning that the
result of it can again be installed, as it will also produce a
strippe
On 14 October 2011 15:07, "Martin v. Löwis" wrote:
>> I can't really comment on this. I agree in principle with what you're
>> saying, but I know little about the MSI format so I can't say much
>> more. It feels to me like you're suggesting that the MSI file
>> encapsulate the file layout logic th
Thanks for the clarification. I can see why this would be important.
But maintaining 3 different interfaces to do essentially the same
thing (collect some data from the user, then based on that data put
the same set of files in the same places) seems a waste of effort, and
a recipe for discrepanci
I can't really comment on this. I agree in principle with what you're
saying, but I know little about the MSI format so I can't say much
more. It feels to me like you're suggesting that the MSI file
encapsulate the file layout logic that already has to exist in
pysetup, though, which sounds like d
On Thursday, October 13, 2011 04:02:27 PM Jeremy Kloth wrote:
> That said, I have been working on a drop-in replacement for the current
> bdist_wininst executable stub with the following features:
> - install to 32- or 64-bit Python installations from a single installer;
> currently one installer
On Thursday, October 13, 2011 01:42:13 PM Paul Moore wrote:
> Maybe the wininst and MSI installers should ultimately become simple
> UIs around a zipfile and an invocation of the packaging APIs? Not that
> I'm offering to do that work, I'm afraid...
The bdist_wininst/_msi installers cannot use any
On Tuesday, October 11, 2011 01:59:45 AM Vinay Sajip wrote:
> I looked at the dialog resources for wininst-x.y.exe and noticed that there
> is a "Find other ..." button which is hidden, and its handler (in
> PC\bdist_wininst\install.c) is commented out. However, the code called by
> the handler - G
On 13 October 2011 20:28, Tim Golden wrote:
> On 13/10/2011 19:36, Paul Moore wrote:
>>
>> I don't really understand the benefits of bdist_msi over
>> bdist_wininst
>
> Just commenting on this particular issue: in essence, the .MSI
> format is the Microsoft standard, something which is especially
On 13/10/2011 19:36, Paul Moore wrote:
I don't really understand the benefits of bdist_msi over
bdist_wininst
Just commenting on this particular issue: in essence, the .MSI
format is the Microsoft standard, something which is especially
important for corporate rollouts. We're not particularly b
On 13 October 2011 18:30, "Martin v. Löwis" wrote:
>> wininst and msi bdists can continue to be used as previously, for people
>> who want clicky installation to their system Python. With built-in
>> package management and virtual environments in 3.3+, we can just
>> recommend that people publish
On 13 October 2011 17:25, Éric Araujo wrote:
>> 1. By using setup.cfg technology, it would be easy enough to zip up a
>> binary build in a way that pysetup could unpack and install.
> Correct. I’m still pondering whether I find the idea of registering
> built files in setup.cfg as elegant or hack
wininst and msi bdists can continue to be used as previously, for people
who want clicky installation to their system Python. With built-in
package management and virtual environments in 3.3+, we can just
recommend that people publish bdist_simple instead of wininst or eggs.
Pardon me for jumpi
On 13 October 2011 17:35, Éric Araujo wrote:
> Le 11/10/2011 03:29, Nick Coghlan a écrit :
>> On Mon, Oct 10, 2011 at 2:29 PM, Paul Moore wrote:
>>> Ideally bdist_wininst and bdist_msi would also integrate with pysetup
>>> and with virtual environments, but I imagine that could be pretty hard
>>>
Le 13/10/2011 18:25, Éric Araujo a écrit :
>>2c. There's a question over a GUI install followed by a pysetup
>> uninstall, which wouldn't remove the add/remove entry...
> I think we could require that a project installed with a clicky
> wininst_bdist has to be removed via the Add/Remove GUI. (
Hi Nick,
Le 11/10/2011 03:29, Nick Coghlan a écrit :
> On Mon, Oct 10, 2011 at 2:29 PM, Paul Moore wrote:
>> Ideally bdist_wininst and bdist_msi would also integrate with pysetup
>> and with virtual environments, but I imagine that could be pretty hard
>> to make work cleanly, as Windows doesn't
Le 09/10/2011 22:14, Paul Moore a écrit :
> On 9 October 2011 20:47, Tarek Ziadé wrote:
>> PEP 376 provide the installation format for the 'future' --
>> http://www.python.org/dev/peps/pep-0376/
> [...]
>> Now for a binary archive, that would get installed ala PEP 376, why
>> not ? I'd just be cur
Hi Philip,
> [...] In any case, it definitely wasn't the case that eggs or setuptools were
> rejected for 2.5; they were withdrawn for reasons that didn't have anything
> to do with the format itself.
Thanks for clarifying. I nonetheless remember strong opposition to
pulling the code unmodified,
Le 09/10/2011 13:54, Paul Moore a écrit :
> On 9 October 2011 08:15, Éric Araujo wrote:
>> Are there that many distributions with extension modules? sdists should
>> work well even on Windows for pure Python projects.
> [...]
> Looking at my installations, I see:
> - database drivers (cx_Oracle,
Le 11/10/2011 09:59, Vinay Sajip a écrit :
> To me it does, and it would be useful to have some validation from
> the packaging folks.
I’m trying to catch up, but the wi-fi here is horrible and there are so
many messages! I’ll compose a reply for tomorrow.
Regards
___
Paul Moore gmail.com> writes:
> To summarise, then:
>
> 1. By using setup.cfg technology, it would be easy enough to zip up a
> binary build in a way that pysetup could unpack and install.
>1a. A packaging command to build such an archive would be worth providing.
> 2. A GUI installer would
On Mon, Oct 10, 2011 at 2:29 PM, Paul Moore wrote:
> Ideally bdist_wininst and bdist_msi would also integrate with pysetup
> and with virtual environments, but I imagine that could be pretty hard
> to make work cleanly, as Windows doesn't really support multiple
> installations of a software packa
On 10 October 2011 21:38, Vinay Sajip wrote:
>> I'm not sure what you mean by a "setup.cfg-based directory". Could
>
>> you
>> clarify, and maybe explain how you'd expect to create such an archive?
>> We may be talking at cross-purposes here.
>
> Here's how I see it: at present, you can install a
> I'm not sure what you mean by a "setup.cfg-based directory". Could
> you
> clarify, and maybe explain how you'd expect to create such an archive?
> We may be talking at cross-purposes here.
Here's how I see it: at present, you can install a project by specifying
pysetup3 install path-to-direc
On 10 October 2011 17:12, Vinay Sajip wrote:
> Paul Moore gmail.com> writes:
>
>> I'd propose that the install arguments used in bdist_wininst be
>> transferred to bdist_dumb (or a new command bdist_binary created based
>> on the same), because the bdist_wininst zip format has the following
>> ad
Paul Moore gmail.com> writes:
> I'd propose that the install arguments used in bdist_wininst be
> transferred to bdist_dumb (or a new command bdist_binary created based
> on the same), because the bdist_wininst zip format has the following
> advantages:
>
> 1. Proven format, so it should deal wi
On 10/10/2011 12:58, Paul Moore wrote:
I've now installed VS Pro 2010. We'll see how that goes. I'd rather
avoid downgrading to VS2008 (or having both at once) just for personal
builds. But will if I have to.
Fairly sure VS2010 won't work, Paul.
At least it didn't when I was in the same situat
On 10 October 2011 12:47, Nick Coghlan wrote:
> IIRC, even the Express edition should still work once the 64 bit
> Platform SDK is installed. Regardless, the intent is that it should be
> possible to build Python with only the free tools from MS. If they
> broke the Express editions such that extr
On Mon, Oct 10, 2011 at 7:49 PM, Paul Moore wrote:
> I'd propose that the install arguments used in bdist_wininst be
> transferred to bdist_dumb (or a new command bdist_binary created based
> on the same)
bdist_zip, bdist_archive, bdist_simple would all work (bdist_binary is
redundant, given what
2011/10/10 PJ Eby :
> On Sun, Oct 9, 2011 at 4:14 PM, Paul Moore wrote:
>>
>> As regards the format, bdist_dumb is about the right level - but
>> having just checked it has some problems (which if I recall, have been
>> known for some time, and are why bdist_dumb doesn't get used).
>> Specifically
On Sun, Oct 9, 2011 at 4:14 PM, Paul Moore wrote:
> As regards the format, bdist_dumb is about the right level - but
> having just checked it has some problems (which if I recall, have been
> known for some time, and are why bdist_dumb doesn't get used).
> Specifically, bdist_dumb puts the locati
On 9 Oct 2011, at 21:14, Paul Moore wrote:
> On 9 October 2011 20:47, Tarek Ziadé wrote:
>> On Sun, Oct 9, 2011 at 9:31 PM, PJ Eby wrote:
>> ...
What we can do however
is to see what bdist_egg does and define a new bdist command inspired by
it, but without zipping, pkg_resource cal
On 9 October 2011 20:47, Tarek Ziadé wrote:
> On Sun, Oct 9, 2011 at 9:31 PM, PJ Eby wrote:
> ...
>>> What we can do however
>>> is to see what bdist_egg does and define a new bdist command inspired by
>>> it, but without zipping, pkg_resource calls, etc.
>>
>> Why? If you just want a dumb bdist
On Sun, Oct 9, 2011 at 9:31 PM, PJ Eby wrote:
...
>> What we can do however
>> is to see what bdist_egg does and define a new bdist command inspired by
>> it, but without zipping, pkg_resource calls, etc.
>
> Why? If you just want a dumb bdist format, there's already bdist_dumb.
> Conversely, if
On Sun, Oct 9, 2011 at 3:15 AM, Éric Araujo wrote:
> After all, if setuptools and then pkg_resources were turned
> down for inclusion in Python 2.5, it’s not now that we have packaging
that we’ll change our mind and just bless eggs.
Actually, that's not what happened. I withdrew the approved
On 9 October 2011 08:15, Éric Araujo wrote:
>> But one thing struck me - the "Installing Python Projects" document
>> talks about source distributions, but not much about binary
>> distributions.
> This is inherited from distutils docs, not a deliberate choice. We just
> haven’t thought much, if
Hi Paul,
Thanks for raising this during the development phase.
> I see that the Packaging documentation is now more complete (at least
> at docs.python.org) - I don't know if it's deemed fully complete yet,
> but I scanned the documentation and "Installing Python Projects" looks
> pretty much con
I see that the Packaging documentation is now more complete (at least
at docs.python.org) - I don't know if it's deemed fully complete yet,
but I scanned the documentation and "Installing Python Projects" looks
pretty much converted (and very good!!), but "Distributing Python
Projects" still has qu
54 matches
Mail list logo
