Just adding my two cents about this problem: I have Microsoft Visual
Studio 2005 and Visual Studio 2008 installed on the same computer, and
they both take up 1.5GB+ of disk space (each!). I'm guessing there's a
lot (probably 1GB+) of stuff in there that could be shared and isn't, so
it's kinda silly to worry about 2MB of disk space.
Remember: If you're really worried about squeezing every last ounce out
of your program, Python probably isn't the language for you. Even
die-hard Python fans will admit that well-tuned C will give you better
performance and smaller executables, on any platform.
Look on the bright side, Mohamed: py2exe is free. If you're not 100%
satisfied, I'm sure Jimmy will be more than happy to give you 100% of
your money back. :-)
BTW, thanks to Jimmy and Thomas for the new 0.6.8 release!
Jimmy Retzlaff wrote:
> On 6/14/08 6:13 PM, "Mohamed Yousef" <harrrrpo@...> wrote:
>> On Sun, Jun 15, 2008 at 2:23 AM, Larry Bates <larry.bates@...> wrote:
>>> Mohamed Yousef wrote:
>>>> why can't we store only one on System32 folder and thus lowerage size
>>> This is a feature not a problem.
>> two points to mention here :
>> 1) versionaning problems can be easily got rid of through naming dlls
>> 2)if this is a feature can you till me how to turn it off ?.. i mean
>> if i don't want it
> Larry indicated that it is a feature, not an optional feature. :) To turn
> it off you will probably have to modify the py2exe source. Unless Thomas
> disagrees with me, I don't think we'll be working on this anytime soon.
>>> If you want several applications to share pythondll, you can build them all
>>> once with a single py2exe script and they will. Larger applications do this
>>> very commonly.
>> but what about apps from different companies you can't do this here
>> and i think there must be a neater solution from inside py2exe like
>> modifying dll call/load
> This is a persistent problem in Windows. Even if you solve the versioning
> problem, you need to solve the installation problem. Either your users need
> to run two installers if Python isn't already installed (as Michael talked
> about with the .NET type approach) or each application needs to include and
> handle installing/uninstalling the shared DLLs. Then each application runs
> the risk of another application uninstalling the shared DLLs. In the 90s the
> state-of-the-art for this problem was a "wonderful" approach where
> uninstallers would actually ask the user about each DLL and whether it
> should be removed from the system directory. I've seen uninstallers from
> big-name software companies ask about the removal of dozens of DLLS, one at
> a time.
> Microsoft's own advice has been all over the map on this in the last decade.
> First they said to install shared copies, then they said to install private
> copies in the app directory, then they came up with the SxS mechanism, then
> they essentially punted on "native" DLLs and said to use .NET assemblies.
>>> I also agree with Michael Foord (see separate post). It is not worth worrying
>>> about 2Mb any more. I installed Acrobat Professional the other day and
>>> that I had installed my first application that was over 1Gb!
>> 2Mb may be small but this destroys the whole idea of resuablility
>> /library sharing / dynamic linking
>> this is just not logical enough EVEN if pythondll was 2kb
>> another thing isn't there any warkaround also for *.pyd files can't
>> they be shared ?
>> for a simple Qt app you have 8Mb of pyd's that have to be distributed
>> with every program file
>> (here we assume one distribution of ~12Mb of Qt dlls )
> I'm not sure I agree with you here. Reusability of what? With the py2exe
> approach you do get code reuse - you don't have to rewrite the Python
> interpreter or Qt. You don't get RAM reuse, but this type of DLL is almost
> always loaded into the process and so they don't share RAM across
> applications anyway. You also don't get to share hard drive space, but it's
> easy to find hard drives for less than US$0.50 per gigabyte (even laptop
> drives). In your 12MB example we're talking about wasting a fraction of a
> penny per application.
> Dynamic linking doesn't help you with the Python interpreter itself unless
> you plan to unload the interpreter and load another one in - code that needs
> to do that would be very "interesting." :) Dynamic linking is useful for
> dynamic plug-ins that the user can load and unload at runtime, but those are
> Finally, for a robust platform approach you need to include a LOT of
> libraries (or require the app to be used on broadband so new ones can be
> downloaded dynamically). You like Qt, but I like wx - our platform just went
> from 12MB to 25MB. Users are likely to have a lot of libraries installed
> that none of their apps use - this might even waste more space than
> duplicate DLLs.
> Just because a few of us disagree with this approach doesn't mean it doesn't
> have merit. You might want to see if this is still being pursued:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.