Support nightly-build download

[xyb <xieyanbo@…>]

Django's evolution is keep walking, getting the lastest code must use subversion. Supporting nightly-build download could be more user-friendly.

[Adrian Holovaty]

#1741 was a duplicate.

[jpaulofarias at gmail dot com]

As an alternative to providing a nightly tarball, I've created a simple script to download code using http :o)

import os
import sys
import urllib
import sgmllib

class HtmlParser(sgmllib.SGMLParser):
    
    def reset(self):
        self.links = []
        sgmllib.SGMLParser.reset(self)
        
    def start_a(self, attrs):
        attrs = dict(attrs)
        if not attrs['href'].startswith('http://') and not attrs['href'] == '../':
            self.links.append(attrs['href'])
    

def download(url, basedir):
    fp = urllib.urlopen(url)
    data = fp.read()
    fp.close()
    parser = HtmlParser()
    parser.feed(data)
    parser.close()
    
    for link in parser.links:
        if link.endswith('/'):
            dirname = link[:-1]
            print 'entering', basedir + link
            try:
                os.mkdir(basedir + dirname)
            except:
                pass
            download(url + link, basedir + link)
        else:
            print 'downloading', url + link
            fp = urllib.urlopen(url + link)
            data = fp.read()
            fp.close()
            
            fp = open(basedir + link, 'w+')
            fp.write(data)
            fp.close()
    
def main():
    download('http://code.djangoproject.com/svn/django/trunk/',  './')
    
if __name__ == '__main__':
    main()

PS: Sorry adrian, I've changed it to high priority by mistake.

[anonymous]

windows users need to change line 41 to:

fp = open(basedir + link, 'wb+')

to have the images download correctly.

[Chris Beaven]

Is this going to happen? Someone with power, make a decision.

[Malcolm Tredinnick]

This would be nice to have some day. It's not a high priority at the moment, but we have discussed it in the past and thought it would reasonable. The main reason not to dismiss it out of hand is that some corporate proxies are set up in a sufficiently b0rked fashion that they cannot be used for subversion access, so providing a tarball download is necessary.

To do this properly, we would actually need, say, one tarball for each of the last N days (N = 3 or 5, say), so that if one day has a broken tarball, there is still a backup.

[Jannis Leidel <jl@…>]

Initial approach of a nightly serving app for django_website using pysvn

[Jannis Leidel <jl@…>]

Fixes a typo

[Jannis Leidel <jl@…>]

Adds version labels to archive filenames to differ them when creating archives with the included cron utility

[Brian Rosner <brosner@…>]

I really would like to see a nightly tarball for download. Would rather wget http://nightlytarball than svn export and create my own ;)

Wouldn't this be better as a post commit hook and provide an archive of the last five commits?

[Jannis Leidel <jl@…>]

Good point, running a script after a commit should be straight forward with the current code in build_nightlies.py. Just run the build_nightlies.py script and the daily nightly (??) will be build.

But maby it makes more sense to come up with snapshots instead of nightlies anyway, tagging the archive files with the revision number.
Can we can please get a signal from one of the main devs?

[Malcolm Tredinnick]

It's not going to be a good idea to generate a new tarball after every commit. Commits are often very small changes, sometimes just one, two or five lines and there can be many of them close together. So sometimes we'll be generating tarballs more or less continuall and they won't be that different under that model.

Generating a tarball every 24 hours is a more reasonable interval and we can just keep the last five or so hanging around at any given moment (in case the most recent one is busted for some reason, which can easily happen).

[Jannis Leidel <jl@…>]

Fair enough, the current patch creates the archives (tar.gz, tar.bz2 and zip) from the current trunk of every DocumentRelease object from the django_website project.
I hope you feel like really using this, I think it is very useful.

[Simon G. <dev@…>]

I've marked this as ready to checkin, since the last patch here seems to take into account all the comments and is good to go. Setting it up on the website, however, might take some time. I do think it's a good idea to get this in action soon, as it's probably less use post-1.0

[Jannis Leidel]

Ha! I had already forgotten this patch. Thanks PJCrosier :)

[anonymous]

Replying to jpaulofarias at gmail dot com:

Replace the last two function calls with this to specify a folder to download to at the command prompt.

def main(loc):
    download('http://code.djangoproject.com/svn/django/trunk/',  loc)
    
if __name__ == '__main__':
    try:
        loc = sys.argv[1]
    except IndexError:
	loc = "./"
    main(loc)

[Jannis Leidel]

So, what's the status on that? Do we really need nightlies now that we have a roadmap?

[Karen Tracey <kmtracey@…>]

Actually I think this idea might be more important as the project gets closer to 1.0 release. Having a daily tarball that is produced by the same tools as will produce the official release and made available for people to test would give wider opportunity for finding bugs in the tarball-creation process plus in the install-from-tarball scenario which few regular contributors ever exercise.

[Jannis Leidel]

Interesting point! I'm not sure what's the process of producing a official release though, while I imagine it's just running python setup.py sdist. But I like the idea to have that process automated. IIRC the last patch would need some work then, even if it already shares some code with distutils.

[George Vilches]

We're long past 1.0 (1.1 even!), and no one's asked for this in over a year. Is this still of interest? It'd be nice to see yet one more low bug number closed. :)

[Adam Nelson]

Nobody has complained about potentially closing this for close to a year and nowadays just using svn (or a git/mercurial clone) is so much more sensible than a tarball. setup.py can be run much more cleanly from trunk with:

pip install -U -e svn+http://code.djangoproject.com/svn/django/trunk/#egg=django

Can somebody just close it? Can I just close it?

[Chris Beaven]

You can always bring it up on django-dev group if you're unsure (personally I think that spending any time on this would be redundant).

[Russell Keith-Magee]

IMHO, this is still a useful "someday, maybe" goal. Not because a nightly tarball is a particularly useful artefact -- I agree that a (D)VCS checkout is much more appropriate way of handling regular updates. However, the tooling and processes required to get a nightly tarball is a useful resource. In order to have a nightly tarball, we must have a completely automated build and packing process. That means that the packing bugs (such as the accidental packaging of .DS_Store in #11520) can be avoided by process, rather than by convention. It also means that we are *always* in a position to cut a release - we just take the tarball on the top of the pile and relabel it (or push a slightly different button on the nightly build process).

"Someday, maybe" is the best description for this. It would be nice if it were to happen, but it's not a huge priority, and we can live with what we have for the moment.

[Eric Holscher]

Would it be useful to note in the documentation that ​http://github.com/django/django/archives/master is a place to get a tarball of the latest bits of django? This wouldn't necessarily solve the part about the automated build process, but it's at least a tarball we could offer people of the latest bits.

I can talk to james about this and see if we can set up a fabric script that would handle the release process and then get that automate as well.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Aviral Dasgupta]

This should be trivial to fix, now that Django is hosted on Github. (​They have an automatic "nightly" link.)

[Aymeric Augustin]

IMO creating a zip of the repo and making a release are different tasks. This ticket is about the former.

As suggested by aviraldg, I'm going to just add a link to the zip provided by GitHub. We have a precedent for this — the PDF of the docs provided by RTD.

[Aymeric Augustin]

I've updated the download page: ​https://www.djangoproject.com/download/