Opened 19 years ago

Closed 13 years ago

#1327 closed New feature (fixed)

Support nightly-build download

Reported by: xyb <xieyanbo@…> Owned by:
Component: *.djangoproject.com Version:
Severity: Normal Keywords: svn nightly snapshot sprintsept14
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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

Attachments (3)

nightly.diff (7.3 KB ) - added by Jannis Leidel <jl@…> 18 years ago.
Initial approach of a nightly serving app for django_website using pysvn
nightly2.diff (7.3 KB ) - added by Jannis Leidel <jl@…> 18 years ago.
Fixes a typo
nightly3.diff (7.4 KB ) - added by Jannis Leidel <jl@…> 18 years ago.
Adds version labels to archive filenames to differ them when creating archives with the included cron utility

Download all attachments as: .zip

Change History (39)

comment:1 by Adrian Holovaty, 19 years ago

priority: normallowest
Severity: normaltrivial

comment:2 by Adrian Holovaty, 19 years ago

#1741 was a duplicate.

comment:3 by anonymous, 19 years ago

priority: lowesthigh

comment:4 by Adrian Holovaty, 19 years ago

priority: highlow

comment:5 by jpaulofarias at gmail dot com, 19 years ago

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.

comment:6 by anonymous, 18 years ago

windows users need to change line 41 to:

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


to have the images download correctly.

comment:7 by Chris Beaven, 18 years ago

Triage Stage: UnreviewedDesign decision needed

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

comment:8 by Malcolm Tredinnick, 18 years ago

Triage Stage: Design decision neededAccepted

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.

by Jannis Leidel <jl@…>, 18 years ago

Attachment: nightly.diff added

Initial approach of a nightly serving app for django_website using pysvn

comment:9 by Jannis Leidel <jl@…>, 18 years ago

Summary: Support nightly-build download[PATCH] Support nightly-build download

by Jannis Leidel <jl@…>, 18 years ago

Attachment: nightly2.diff added

Fixes a typo

by Jannis Leidel <jl@…>, 18 years ago

Attachment: nightly3.diff added

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

comment:10 by Marc Fargas <telenieko@…>, 18 years ago

Has patch: set

comment:11 by Brian Rosner <brosner@…>, 18 years ago

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?

comment:12 by Jannis Leidel <jl@…>, 18 years ago

Keywords: svn nightly snapshot added

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?

comment:13 by Malcolm Tredinnick, 18 years ago

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).

comment:14 by Jannis Leidel <jl@…>, 18 years ago

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.

comment:15 by Simon G. <dev@…>, 17 years ago

Triage Stage: AcceptedReady for checkin

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


comment:16 by anonymous, 17 years ago

Keywords: sprintsept14 added

comment:17 by Pete Crosier, 17 years ago

Summary: [PATCH] Support nightly-build downloadSupport nightly-build download

comment:18 by Jannis Leidel, 17 years ago

Owner: changed from nobody to Jannis Leidel

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

comment:19 by Jacob, 17 years ago

Triage Stage: Ready for checkinSomeday/Maybe


in reply to:  5 comment:20 by anonymous, 17 years ago

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)

comment:21 by Jannis Leidel, 16 years ago

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

comment:22 by Karen Tracey <kmtracey@…>, 16 years ago

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.

comment:23 by Jannis Leidel, 16 years ago

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.

comment:24 by Jannis Leidel, 16 years ago

Status: newassigned

comment:25 by George Vilches, 15 years ago

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. :)

comment:26 by Jannis Leidel, 15 years ago

Owner: Jannis Leidel removed
Status: assignednew

comment:27 by Adam Nelson, 15 years ago

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?

comment:28 by Chris Beaven, 15 years ago

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).

comment:29 by Russell Keith-Magee, 15 years ago

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.

comment:30 by Eric Holscher, 14 years ago

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.

comment:31 by Łukasz Rekucki, 14 years ago

Severity: trivialNormal
Type: enhancementNew feature

comment:32 by Aymeric Augustin, 13 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:33 by Aymeric Augustin, 13 years ago

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:34 by Aviral Dasgupta, 13 years ago

Triage Stage: Someday/MaybeAccepted

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

comment:35 by Aymeric Augustin, 13 years ago

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.

comment:36 by Aymeric Augustin, 13 years ago

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.
Back to Top