T
Timothy Smith
is it possible instead of py2exe putting all library's in a zip file, to
just put them in a sub dir?
just put them in a sub dir?
Timothy said:is it possible instead of py2exe putting all library's in a zip file, to
just put them in a sub dir?
exactly what i just stated, i don't want py2exe to zip up it'sPeter said:Timothy Smith wrote:
Anything's possible. Maybe you could explain what you're actually
trying to accomplish (or the reasons) so we can better understand where
you're going with this...
-Peter
exactly what i just stated, i don't want py2exe to zip up it's
library's, but to put them in a sub dir.
the reason for this, is so that when users login and update from svn,
they only have to download some tiny pyc files, not a great big zip file
with everything in it ( 99% of which never changes)
version control systems are used for many purposes. it's just as
important to keep track of your packaged releases and documentation as
it is source code.
its also a very convenient method of keeping people up with the lastest
version.
i know i've seen what i'm asking for before, but no one seems to be able
to tell me.
don't do so well how. all it does is keep of files and tracks theirSimon said:Well, they may be used for many things, but what they are *good* at is
what they were designed for. Use them to do a job that they *weren't*
designed for, and they don't do so well.
but if it was just a dir, when they update from the svn at log in, allThe zip file essentially contains the whole system in on lump. Change
the system, and naturally your users will have to download the whole
lump again. (In my 'day job', I'm a Java web app developer. We keep
the source for our systems in SVN, any 3rd party JARs, and our build
scripts. We *used* to keep the installable WAR files in there too, but
we've stopped doing that now, for this reason amongst others.)
Timothy said:exactly what i just stated, i don't want py2exe to zip up it's
library's, but to put them in a sub dir.
the reason for this, is so that when users login and update from svn,
they only have to download some tiny pyc files, not a great big zip file
with everything in it ( 99% of which never changes)
ideally i'd love to not to have to use py2exe at all, then they can justPeter said:Timothy Smith wrote:
More detail on this version control thing would probably help. (Things
like that are why I asked fo more background... "exactly what I stated"
isn't as useful as something like (for example) "I want my app users to
use Subversion to retrieve updates to the application without having to
download a big zip file".)
Do you know that Subversion has (as I understand it) a fairly
intelligent binary file comparison routine, and it will (again, as I
understand it) not transmit the entire contents of the zip file but
would actually send only the portions that have changed? At least,
that's if the file isn't compressed in some way that prevents this
algorithm from working well. (Note to self: check if zip files that can
be in sys.path can be compressed, and if py2exe compresses them.)
Anyway, while this sort of thing isn't directly supported (probably
since almost nobody would want to do it, for reasons similar to what
Simon has explained), you should be able to work it out yourself. The
.exe produced by py2exe contains a "stub" executable that basically sets
sys.path to point to the .zip file, then runs the main .py which has
been integrated into the .exe file (not even compiled to a .pyc, just
like normal). If you modify your main .py to adjust sys.path to point
to an external subdirectory, you should be able to leave .py files (or
.pyc files) there and use svn to update them.
I'll leave it as an exercise for the reader (mainly because I don't know
how to do it offhand) what you should do to prevent py2exe from putting
all your files in its zip. It should probably still put the standard
library modules there, since otherwise you'd have little reason to be
using py2exe in the first place...
-Peter
Peter Hansen said:[ ... ] (Note to self: check if zip files that can
be in sys.path can be compressed,
Yes.
and if py2exe compresses them.)
Timothy Smith said:is it possible instead of py2exe putting all library's in a zip file,
to just put them in a sub dir?
Just said:Peter Hansen said:[ ... ] (Note to self: check if zip files that can
be in sys.path can be compressed,
Yes.
and if py2exe compresses them.)
Don't know, but I assume yes.
Peter Hansen said:Do you know that Subversion has (as I understand it) a fairly
intelligent binary file comparison routine, and it will (again, as I
understand it) not transmit the entire contents of the zip file but
would actually send only the portions that have changed? At least,
that's if the file isn't compressed in some way that prevents this
algorithm from working well. (Note to self: check if zip files that
can be in sys.path can be compressed, and if py2exe compresses them.)
David said:Even if the files were compressed, which has a net result similar to
randomizing the contents and will certainly extend the portion that
appears "changed", the worst that would happen is that subversion
(which does use a binary delta algorithm) would end up downloading the
single file portion of the zip file rather than the smaller change
within the file. It should still be efficient.
I've got this working now, and fyi it downloads the entire zip everyDavid said:Even if the files were compressed, which has a net result similar to
randomizing the contents and will certainly extend the portion that
appears "changed", the worst that would happen is that subversion
(which does use a binary delta algorithm) would end up downloading the
single file portion of the zip file rather than the smaller change
within the file. It should still be efficient.
But to be honest, for something like the OPs purpose, it's not clear
that an SCM is needed, since all he's trying to accomplish is bring a
remote copy up to date with the central one. For that you could just
publish a location containing the necessary files and have the users
use something like rsync directly (which is just as efficient in terms
of a binary delta) to update their own local version.
Of course, if the Subversion server is already in place so it's a
convenient server, or if more of the user base already has the client
in place, it should work just about as well.
-- David
Peter Hansen said:Good point. When I wrote that I was picturing the form of compression
that a .tar.gz file would have, not what is actually used inside a
.zip file which is -- quite logically now that you point it out --
done on a file-by-file basis. (Clearly to do otherwise would risk
your data and make changing compressed zips highly inefficient.)
Timothy Smith said:I've got this working now, and fyi it downloads the entire zip every
time. and svn appears to be very slow at it to.
but if it was just a dir, when they update from the svn at log in, allThe zip file essentially contains the whole system in on lump. Change
the system, and naturally your users will have to download the whole
lump again. [...]
they do is download the extra\changed files. much much quicker then
downloading a 4 meg uncompressed zip file.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.