On 16 September 2012 23:26, Vinay Sajip wrote:
> I think all that's needed (at the same level of abstraction) is a method
> write_installed_files(iterable_of_absolute_file_paths) which writes the file.
> This code is already in the distutils2.install_distinfo.install_distinfo.run()
> method. I'll
Paul Moore gmail.com> writes:
> A nice addition would be an API for managing the RECORD file. I would
> imagine functions to read/write the file (hiding the details of how to
> open the CSV file correctly in a cross-platform manner), functions to
> produce a list of the files installed for a dist
On Mon, Sep 17, 2012 at 5:05 AM, Daniel Holth wrote:
>> I agree with Lennart's and Antoine's advice of just move forward with what
>> we have. If some PEPs need fixing then let's fix them, but we don't need to
>> rock the horse even more by going overboard. Getting the sane, core bits
>> into the
> I agree with Lennart's and Antoine's advice of just move forward with what
> we have. If some PEPs need fixing then let's fix them, but we don't need to
> rock the horse even more by going overboard. Getting the sane, core bits
> into the stdlib as packaging is meant to is plenty to take on. If p
On 14 September 2012 16:12, Vinay Sajip wrote:
> I have set up a BitBucket repo called distlib, at
>
> https://bitbucket.org/vinay.sajip/distlib/
>
> This has the following bits of distutils2 / packaging, updated to run on 2.x
> and
> 3.x with a single codebase, and including tests (though not do
On Sep 16, 2012, at 6:37 AM, Chris Jerdonek wrote:
> On Fri, Sep 14, 2012 at 8:12 AM, Vinay Sajip wrote:
>> I have set up a BitBucket repo called distlib, at
>>
>> https://bitbucket.org/vinay.sajip/distlib/
>>
>> ...
>>
>> The code was taken at around the time packaging was removed, and may n
On Fri, Sep 14, 2012 at 8:12 AM, Vinay Sajip wrote:
> I have set up a BitBucket repo called distlib, at
>
> https://bitbucket.org/vinay.sajip/distlib/
>
> ...
>
> The code was taken at around the time packaging was removed, and may not have
> more recent changes.
Would it be possible or make sens
Antoine Pitrou pitrou.net> writes:
> On the other hand, if you are not using hg.python.org features such as
> commits e-mails or buildbots, it's also fine living on bitbucket until
> the project matures a bit.
>
I'm fine with that.
Regards,
Vinay Sajip
___
On Sat, 15 Sep 2012 16:27:28 +0100 (BST)
Vinay Sajip wrote:
> > Depends how much you care about a pristine history - you can do a
>
> > server side clone of an existing repo and then empty it out. And if
> > you use http://hg.python.org/buildbot/empty/ as the starting point,
> > there isn't even
> Depends how much you care about a pristine history - you can do a
> server side clone of an existing repo and then empty it out. And if
> you use http://hg.python.org/buildbot/empty/ as the starting point,
> there isn't even anything to empty out.
Actually there are some files in there - a Make
On Sat, Sep 15, 2012 at 11:43 PM, Vinay Sajip wrote:
> Sure, but I don't know if I can do it. IIUC it needs someone with an account
> on
> the server to create new repositories.
Depends how much you care about a pristine history - you can do a
server side clone of an existing repo and then empty
Tarek Ziadé ziade.org> writes:
> > Regards,
> oh, cool !
>
> maybe we could copy it at hg.python.org ?
>
Sure, but I don't know if I can do it. IIUC it needs someone with an account on
the server to create new repositories.
Regards,
Vinay Sajip
__
On 9/14/12 5:12 PM, Vinay Sajip wrote:
Nick Coghlan gmail.com> writes:
I like "distcore" or "distlib", though.
I have set up a BitBucket repo called distlib, at
https://bitbucket.org/vinay.sajip/distlib/
This has the following bits of distutils2 / packaging, updated to run on 2.x and
3.x w
Nick Coghlan gmail.com> writes:
>
> I like "distcore" or "distlib", though.
>
I have set up a BitBucket repo called distlib, at
https://bitbucket.org/vinay.sajip/distlib/
This has the following bits of distutils2 / packaging, updated to run on 2.x and
3.x with a single codebase, and includin
On Thu, Sep 13, 2012 at 5:38 AM, Antoine Pitrou wrote:
> On Thu, 13 Sep 2012 11:14:17 +1000
> Nick Coghlan wrote:
>> On Thu, Sep 13, 2012 at 8:43 AM, R. David Murray
>> wrote:
>> > When the removal was being pondered, the possibility of keeping certain
>> > bits that were more ready than others
On Fri, Sep 14, 2012 at 12:39 AM, Éric Araujo wrote:
> Hi,
>
> Le 13/09/2012 10:34, Nick Coghlan a écrit :
>> Actually, I'd be happy to do the rearrangement needed to turn pkgutil
>> into a package rather than the current single module.
>
> I very much prefer not mixing pkgutil (dealing with packa
On Fri, Sep 14, 2012 at 12:39 AM, Éric Araujo wrote:
> Hi,
>
> Le 13/09/2012 10:34, Nick Coghlan a écrit :
>> Actually, I'd be happy to do the rearrangement needed to turn pkgutil
>> into a package rather than the current single module.
>
> I very much prefer not mixing pkgutil (dealing with packa
Hi,
Le 13/09/2012 10:34, Nick Coghlan a écrit :
> Actually, I'd be happy to do the rearrangement needed to turn pkgutil
> into a package rather than the current single module.
I very much prefer not mixing pkgutil (dealing with packages that you
import) and build/distribution/installation support
On Fri, Sep 14, 2012 at 12:34 AM, Nick Coghlan wrote:
> Anyway, the essential idea of getting those 4 modules (and support
> libraries) that almost made it into 3.3 into sufficiently good shape
> that they can be distributed independently of distutils2 and adopted
> as a dependency by multiple pro
On Thu, Sep 13, 2012 at 9:47 PM, Chris Jerdonek
wrote:
> On Thu, Sep 13, 2012 at 4:32 AM, Tarek Ziadé wrote:
>> Here's my proposal - actually it's Nick's proposal but I want to make sure
>> we're on the same
>> page wrt steps, and I think that addresses Antoine concerns
>>
>> 1. create a new pack
On 9/13/12 2:45 PM, Paul Moore wrote:
4. ask each project to pour in pkglib anything that can be reused by others
+1, although again it'll be down to the projects whether they do
actually contribute. Also this somewhat contradicts the "be strict"
point above, which is why I'm lukewarm on "be str
On 13 September 2012 12:32, Tarek Ziadé wrote:
> Here's my proposal - actually it's Nick's proposal but I want to make sure
> we're on the same
> page wrt steps, and I think that addresses Antoine concerns
>
> 1. create a new package, called pkglib (or whatever), located at hg
> .python.org as a n
On Thursday, September 13, 2012 at 7:32 AM, Tarek Ziadé wrote:
>
> Yeah but we've been too ambitious.
>
> Here's my proposal - actually it's Nick's proposal but I want to make
> sure we're on the same
> page wrt steps, and I think that addresses Antoine concerns
>
> 1. create a new package,
On Thu, Sep 13, 2012 at 4:32 AM, Tarek Ziadé wrote:
> Here's my proposal - actually it's Nick's proposal but I want to make sure
> we're on the same
> page wrt steps, and I think that addresses Antoine concerns
>
> 1. create a new package, called pkglib (or whatever), located at hg
> .python.org a
On 9/13/12 11:38 AM, Antoine Pitrou wrote:
On Thu, 13 Sep 2012 11:14:17 +1000
Nick Coghlan wrote:
On Thu, Sep 13, 2012 at 8:43 AM, R. David Murray wrote:
When the removal was being pondered, the possibility of keeping certain
bits that were more ready than others was discussed. Perhaps the b
On Thursday, September 13, 2012 at 5:38 AM, Antoine Pitrou wrote:
> Most people use distutils / packaging as
> an application, not a library. If you provide only a subset of
> the necessary features, people won't use packaging.
Not that I think current usage patterns matter since moving from setup
On Thu, 13 Sep 2012 11:14:17 +1000
Nick Coghlan wrote:
> On Thu, Sep 13, 2012 at 8:43 AM, R. David Murray
> wrote:
> > When the removal was being pondered, the possibility of keeping certain
> > bits that were more ready than others was discussed. Perhaps the best
> > way forward is to put it b
On Thu, Sep 13, 2012 at 8:43 AM, R. David Murray wrote:
> When the removal was being pondered, the possibility of keeping certain
> bits that were more ready than others was discussed. Perhaps the best
> way forward is to put it back in bits, with the most finished (and PEP
> relevant) stuff goin
On Wed, 12 Sep 2012 18:07:42 -0400, Brett Cannon wrote:
> On Wed, Sep 12, 2012 at 3:28 PM, Lennart Regebro wrote:
>
> > On Wed, Sep 12, 2012 at 9:02 PM, Ãric Araujo wrote:
> > > âfind a PEP dictator and propose changesâ. And when I started the
> > > thread about removing packaging in 3.3,
On Wed, Sep 12, 2012 at 3:28 PM, Lennart Regebro wrote:
> On Wed, Sep 12, 2012 at 9:02 PM, Éric Araujo wrote:
> > “find a PEP dictator and propose changes”. And when I started the
> > thread about removing packaging in 3.3, hundreds of replies discussed
> > changing the whole distutils architec
> I'm happy to note that as of version 0.6.28 distutils (the setuptools
> fork)
You certainly mean distribute. :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
On Wed, Sep 12, 2012 at 3:28 PM, Lennart Regebro wrote:
> On Wed, Sep 12, 2012 at 9:02 PM, Éric Araujo wrote:
>> “find a PEP dictator and propose changes”. And when I started the
>> thread about removing packaging in 3.3, hundreds of replies discussed
>> changing the whole distutils architecture
On Wed, Sep 12, 2012 at 9:02 PM, Éric Araujo wrote:
> “find a PEP dictator and propose changes”. And when I started the
> thread about removing packaging in 3.3, hundreds of replies discussed
> changing the whole distutils architecture, splitting the project,
> exploring new systems, etc.,
Yes,
On Thu, Sep 13, 2012 at 7:02 AM, Éric Araujo wrote:
> Hi,
>
> Lib/packaging is in the repository history, and in my backup clones, but
> it’s not visible in any branch head as we have no branch for 3.4 yet. I
> can bring the directory back with a simple Mercurial command.
>
> However, it’s not cl
On Wed, 12 Sep 2012 15:02:42 -0400
Éric Araujo wrote:
> Hi,
>
> Lib/packaging is in the repository history, and in my backup clones, but
> it’s not visible in any branch head as we have no branch for 3.4 yet. I
> can bring the directory back with a simple Mercurial command.
>
> However, it’s no
Hi,
Lib/packaging is in the repository history, and in my backup clones, but
it’s not visible in any branch head as we have no branch for 3.4 yet. I
can bring the directory back with a simple Mercurial command.
However, it’s not clear to me that we want to do that. At the inception
of the proje
Hello
I was wondering if anyone knows if the removed Lib/packaging directory
landed in some other places after it was removed.
We have http://hg.python.org/distutils2 be the 'packaging' version is a
full py3-renamed version we need to keep mirrored
Cheers
Tarek
_
Hi Carl,
Thanks for clarifying this.
This means that indeed we have the same goals. I'll have a closer look
at the internal pip APIs, as they are probably really useful and already
used in production environment :)
___
Python-Dev mailing list
Python
Hi Alexis,
On 06/20/2012 10:57 AM, Alexis Métaireau wrote:
> Le mer. 20 juin 2012 18:45:23 CEST, Paul Moore a écrit :
>> Thanks - as you say, it's not so much the actual problem as the
>> principle of what the packaging API offers that matters here. Although
>> it does make a good point - to what
On 20/06/2012 17:29, Paul Moore wrote:
I wasn't aware of this - I've had a look and my first thought is that
the documentation needs completing. At the moment, there's a lot that
isn't documented, and we should avoid getting into the same situation
as with distutils where people have to use undo
Le mer. 20 juin 2012 18:45:23 CEST, Paul Moore a écrit :
Thanks - as you say, it's not so much the actual problem as the
principle of what the packaging API offers that matters here. Although
it does make a good point - to what extent do the packaging APIs draw
on existing experience like that of
On 20 June 2012 17:07, Carl Meyer wrote:
> Hi Paul,
>
> On 06/20/2012 09:29 AM, Paul Moore wrote:
>> As a specific example, one thing I would like to do is to be able to
>> set up a packaging.pypi client object that lets me query and download
>> distributions. However, rather than just querying Py
Hi Paul,
On 06/20/2012 09:29 AM, Paul Moore wrote:
> As a specific example, one thing I would like to do is to be able to
> set up a packaging.pypi client object that lets me query and download
> distributions. However, rather than just querying PyPI (the default)
> I'd like to be able to set up a
On 20 June 2012 14:47, Paul Moore wrote:
> On 20 June 2012 14:16, Alexis Métaireau wrote:
>> packaging.pypi is functionally working but IMO the API can (and probably
>> should) be improved (we really lack feedback to know that).
>
> I wasn't aware of this - I've had a look and my first thought is
2012/1/24 Alexis Métaireau
> Entrypoints basically are a plugin system. They are storing information in
> the metadata and then retrieving them when needing them. The problem with
> this, as everything when trying to get information from metadata is that we
> need to parse all the metadata for al
On Jan 24, 2012, at 12:54 PM, Alexis Métaireau wrote:
> I'm wondering if we should support that (a way to have plugins) in the new
> packaging thing, or not. If not, this mean we should come with another
> solution to support this outside of packaging (may be in distribute). If yes,
> then we s
Hi folks,
I have this in my mind since a long time, but I didn't talked about that
on this list, was only writing on distutils@ or another list we had for
distutils2 (the fellowship of packaging).
AFAIK, we're almost good about packaging in python 3.3, but there is
still something that keeps
> I'd provide a fixed custom action which gets hold of the installer
> session, and then runs a Python script. IIUC, it should be possible
> to map categories to entries in the Directory table, so that the
> Python script would actually configure the installer process before
> the installer act
> I'm curious to know how this level of flexibility can be achieved with the
> MSI format: I know one can code the equivalent logic in C (for example) in
> a custom action, but don't know how you can keep the logic in Python.
I'd provide a fixed custom action which gets hold of the installer
sessi
>
> It seems to me that there are two separate things going on in this
> sample. It's not 100% clear that they are separate, at first glance,
> as packaging currently doesn't make a strong distinction between
> things going on at "build" time, and things going on at
> "install"
> time. This is es
On 7 November 2011 09:26, Vinay Sajip wrote:
> Martin v. Löwis v.loewis.de> writes:
>
>>
>> Again, that's a bdist_msi implementation issue. It could generate custom
>> actions that run the "proper" setup.cfg hooks (I presume - I have no
>> idea what a setup.cfg hook actually is).
>>
>
> I know th
Martin v. Löwis v.loewis.de> writes:
>
> Again, that's a bdist_msi implementation issue. It could generate custom
> actions that run the "proper" setup.cfg hooks (I presume - I have no
> idea what a setup.cfg hook actually is).
>
I know that custom hooks are quite powerful, but my comment was
> I agree in principle, but one thing you get with setup.cfg which seems harder
> to
> achieve with MSI is the use of Python to do things at installation time. For
> example, with setup.cfg hooks, you can use ctypes to make Windows API calls at
> installation time to decide where to put things. Wh
Urgh. I guess that was already answered. Guess this'll teach me not to
reply to a thread before waiting for ALL the messages to download over a
low-bandwidth connection... (am on the road at the moment and catching up
on stuff in spare cycles - sorry for the noise)
On Fri, Nov 4, 2011 at 10:24
On Sun, Oct 30, 2011 at 6:52 PM, Paul Moore wrote:
> On 30 October 2011 18:04, Ned Deily wrote:
> > Has anyone analyzed the current packages on PyPI to see how many provide
> > binary distributions and in what format?
>
> A very quick and dirty check:
>
> dmg: 5
> rpm: 12
> msi: 23
> dumb: 132
>
On 31 October 2011 18:36, Ned Deily wrote:
> In article
> ,
> Paul Moore wrote:
>> On 30 October 2011 18:04, Ned Deily wrote:
>> > Has anyone analyzed the current packages on PyPI to see how many provide
>> > binary distributions and in what format?
>>
>> A very quick and dirty check:
>>
>> dmg
In article
,
Paul Moore wrote:
> On 30 October 2011 18:04, Ned Deily wrote:
> > Has anyone analyzed the current packages on PyPI to see how many provide
> > binary distributions and in what format?
>
> A very quick and dirty check:
>
> dmg: 5
> rpm: 12
> msi: 23
> dumb: 132
> wininst: 364
> e
Hi,
> I'd like to reopen the discussions on how the new packaging module
> will handle/support binary distributions in Python 3.3. The previous
> thread (see
> http://mail.python.org/pipermail/python-dev/2011-October/113956.html)
> included a lot of good information and discussion, but ultimately
On 31 October 2011 14:22, Antoine Pitrou wrote:
> On Mon, 31 Oct 2011 05:59:09 -0400
> "Eric V. Smith" wrote:
>>
>> It might be true that such systems don't need binary packages on PyPI,
>> but the original question is about binary package support for the
>> packaging module on non-Windows system
On Mon, 31 Oct 2011 05:59:09 -0400
"Eric V. Smith" wrote:
>
> It might be true that such systems don't need binary packages on PyPI,
> but the original question is about binary package support for the
> packaging module on non-Windows systems. I think the answer is clearly
> "yes": I have such sy
Martin v. Löwis v.loewis.de> writes:
> This presumption is false (as is the claim that you need to install the
> MSI to get at the files). It's quite possible to extract the files from
> the MSI without performing the installation. There are actually two ways
> to do that:
> a) perform an "admin
Paul Moore gmail.com> writes:
> Agreed - the "one size fits all" data location is a limitation. I'm
> not sure that in practical terms it is a big issue, though - it's been
> like that since the wininst format was designed, and nobody has ever
> complained. There are certainly cases where package
On 31 October 2011 10:42, "Martin v. Löwis" wrote:
> Am 31.10.2011 09:07, schrieb Vinay Sajip:
> This presumption is false (as is the claim that you need to install the
> MSI to get at the files). It's quite possible to extract the files from
> the MSI without performing the installation. There ar
Am 31.10.2011 09:07, schrieb Vinay Sajip:
> Paul Moore gmail.com> writes:
>
>> Hang on. I'm talking here about repackaging the binary files in the
>> MSI file for use in a pysetup install invocation. As pysetup has no
>> GUI, and doesn't integrate with Add/Remove, there's no issue here. If
>> you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/30/2011 5:14 PM, Tres Seaver wrote:
> On 10/30/2011 02:04 PM, Ned Deily wrote:
>> In article
>> ,
>
>>
>
> Paul Moore wrote:
>
>>> I'd like to reopen the discussions on how the new packaging
>>> module will handle/support binary distributio
Paul Moore gmail.com> writes:
> Hang on. I'm talking here about repackaging the binary files in the
> MSI file for use in a pysetup install invocation. As pysetup has no
> GUI, and doesn't integrate with Add/Remove, there's no issue here. If
> you want a GUI and Add/Remove integration, just run t
On 30 October 2011 23:17, Vinay Sajip wrote:
> Paul Moore gmail.com> writes:
>
>> The MSI format is a little more tricky, mainly because it is a more
>> complex format and (as far as I can tell from a brief check) files are
>> stored in the opaque CAB format, so the only way of getting data out
>
I like binary distribution even under Linux.
I access some Linux machines using same Linux distribution and some of them
doesn't have "python-dev" package or even "build-essensials". (because they are
netbooting so have restricted rootfs size)
So I want build binary package by myself and distribu
Paul Moore gmail.com> writes:
> The MSI format is a little more tricky, mainly because it is a more
> complex format and (as far as I can tell from a brief check) files are
> stored in the opaque CAB format, so the only way of getting data out
> is to do a temporary install somewhere. But I see n
On 30 October 2011 18:04, Ned Deily wrote:
> Has anyone analyzed the current packages on PyPI to see how many provide
> binary distributions and in what format?
A very quick and dirty check:
dmg: 5
rpm: 12
msi: 23
dumb: 132
wininst: 364
egg: 2570
That's number of packages with binary distributi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/30/2011 02:04 PM, Ned Deily wrote:
> In article
> ,
>
>
Paul Moore wrote:
>
>> I'd like to reopen the discussions on how the new packaging
>> module will handle/support binary distributions in Python 3.3.
>> The previous thread (see
>> http:
In article
,
Paul Moore wrote:
> I'd like to reopen the discussions on how the new packaging module
> will handle/support binary distributions in Python 3.3. The previous
> thread (see
> http://mail.python.org/pipermail/python-dev/2011-October/113956.html)
> included a lot of good information
I'd like to reopen the discussions on how the new packaging module
will handle/support binary distributions in Python 3.3. The previous
thread (see
http://mail.python.org/pipermail/python-dev/2011-October/113956.html)
included a lot of good information and discussion, but ultimately
didn't reach a
> 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
1 - 100 of 208 matches
Mail list logo
