> Can you please cite a source for that recommendation? Preferably
> some MSDN documentation.
http://msdn.microsoft.com/en-us/library/aa368269(v=vs.85).aspx
http://wix.sourceforge.net/manual-wix3/add_a_file.htm
Specifically, starting in bold, where it says "In general, you should restrict
yours
> The general recommendation regarding msi packages is that you always,
> always do single-file components (one of the major reasons being for
> patching purposes).
Can you please cite a source for that recommendation? Preferably
some MSDN documentation.
Regards,
Martin
__
Am 03.02.2011 18:58, schrieb Floris Bruynooghe:
> On 3 February 2011 15:38, Michael Urman wrote:
>> Technically this is a problem with the component generation in Python,
>> and for that in particular, a move to WiX could be very helpful. They
>> have stable component code generation which keys of
> Technically this is a problem with the component generation in Python,
> and for that in particular, a move to WiX could be very helpful. They
> have stable component code generation which keys off of location,
> name, platform, etc., but only works for single-file components.
That would be no r
> At work we keep the required stable UUIDs in an ConfigParser-format
> file checked in to the VCS for that purpose.
>
> FWIW our build system uses WiX (v2) currently and if I where to redo
> it, I'd change to msilib and not WiX v3. But never change working
> systems.
No need to do that if you're
> I hadn't thought it through fully, but the preceding paragraph really
> gets to the core of the problem. The maintenance nightmare is security
> updates for private location installations by third parties. The only
> MSI-friendly way to update that code is through releasing an updated
> merge mod
On 3 February 2011 15:38, Michael Urman wrote:
> Technically this is a problem with the component generation in Python,
> and for that in particular, a move to WiX could be very helpful. They
> have stable component code generation which keys off of location,
> name, platform, etc., but only works
On Thu, Feb 3, 2011 at 00:30, "Martin v. Löwis" wrote:
> Another challenge with shared location merge modules is upgrades:
> the Python installer currently doesn't use stable component IDs;
> I think this would cause problems for users of the merge module.
> Providing stable component IDs is a cha
>> As far as the possibility of distributing Python as a merge
>> module? I'd recommend against it. Shared location merge modules are
>> a maintenance nightmare, and private location merge modules may
>> not offer the benefit you need. Better to just install the main
>> Python msi as part of a suit
> I'm really not trying to start a flame war here (my original post
> only asked if there was "thought towards migrating away from
> msilib"). There's legitimate need/desire for a merge module to make
> it easier to package a specific Python version.
Please recognize that this question is entirely
On Wed, 02 Feb 2011 17:30:43 -0800, "Hoyt, David" wrote:
> > Definitely not. Python is easier than XML.
>
> I disagree.
Just as an FYI, I believe that most people in the Python community find
XML much more of a pain than Python. Many of us (especially those of
us who are not web developers) avo
> I found it much easier to use than WiX, which I also tried.
I also used to use the Visual Studio installer projects until I needed
something a lot more robust (e.g., customized UI + localizable strings). msilib
does the job people need it to do and that's fine. I'm really not trying to
argue
> If Python was starting at ground zero, and the choices were to create
> a library or to use WiX, the answer might have been different.
> However with a mature enough library to suit all the needs that anyone
> has been willing to author, it's certainly more work to create the WiX
> install and
> Using msilib is easier than using Wix. It's also more flexible.
IMO, no. It's simply not.
> All you have to know is how the MSI schema works.
Same with WiX.
> It could easily be extended to do so, in a straight-forward manner.
Other packaging apps already have it - no work needed.
> (actual
Martin v. Löwis wrote:
> The Installer COM object is the platform standard
> mechanism, and that's what msilib uses. I really see no need to move
> away from that - it can create arbitrary MSI files.
I've used it to package UpLib for Windows -- see
http://uplib.parc.com/hg/uplib/file/e29e36f751f
>> The Installer COM object is the platform standard mechanism, and
>> that's what msilib uses.
>
> Why maintain a lib when there's (better), free alternatives out there
> that are maintained by Microsoft itself?
Using msilib is easier than using Wix. It's also more flexible.
All you have to know
On Wed, Feb 2, 2011 at 15:27, Hoyt, David wrote:
>> The Installer COM object is the platform standard mechanism, and that's what
>> msilib uses.
>
> Why maintain a lib when there's (better), free alternatives out there that
> are maintained by Microsoft itself? (okay, a group at Microsoft that w
>> Is there or will there be support for python merge modules so we can
>> include python in our installer?
>
>I haven't planned any. Contributions are welcome.
>
>> But has there been thought towards migrating away from msilib and using
>> platform standard tools such as wix (used by ms office, vi
Am 02.02.2011 20:01, schrieb Hoyt, David:
> Is there or will there be support for python merge modules so we can
> include python in our installer?
I haven't planned any. Contributions are welcome.
> But has there been thought towards migrating away from msilib and using
> platform standard tools
19 matches
Mail list logo
