> 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
Is there or will there be support for python merge modules so we can include
python in our installer?
Also, the discussions I saw about windows installers not removing the path on
uninstall is completely false as regards the installers that wix creates, at
least. I've modified the path many tim
20 matches
Mail list logo
