Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improved change logs (and related Markdown support) #658

Closed
wants to merge 13 commits into from
Closed

improved change logs (and related Markdown support) #658

wants to merge 13 commits into from

Conversation

skurfer
Copy link
Member

@skurfer skurfer commented Jan 25, 2012

Two main goals here:

  1. Improve the process that generates the HTML version of the change log (mainly to include links to issues on GitHub)
  2. Make the Markdown Python module available to plug-in projects during build. I’m going to use this in the near future to improve the plug-in documentation process.

A Summary of what’s changed:

  • A copy of Python-Markdown is now part of the repo since it's not installed by default. It was built for Python 2.6 and should work in 10.6 (untested) and 10.7.
  • The Release Notes process in Preflight was rewritten to use Python-Markdown (and add links to issues).
  • The Markdown module is copied to /tmp/QS so plug-in projects will have a predictable place to look for it.
  • PYTHONPATH was defined in the xcconfig files so scripts in plug-in projects can find the module automatically.

And one unrelated change: I noticed the job that copies the Configuration folder was hard-coded to /tmp/QS. I changed it to use QS_BUILD_ROOT instead.

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Jan 25, 2012

Looks fine to me, although I haven't tested it. Before I merge it's probably worth somebody on 10.6 (@HenningJ ?) checking that the python-markdown script runs.

@skurfer
Copy link
Member Author

@skurfer skurfer commented Jan 25, 2012

OK so it seems like you have deleted the ChangesBare.html file

I didn’t see any references to it and thought it must just be an intermediate step to the full version. Easy enough to fix.

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Jan 25, 2012

Somebody wasn't paying enough attention to the 'final releases' section
here: http://qsapp.com/wiki/Release_Process

;-)

Good to see it back now :)

On 25 January 2012 18:22, Rob McBroom <
reply@reply.github.com

wrote:

OK so it seems like you have deleted the ChangesBare.html file

I didnt see any references to it and though it must just be an
intermediate step to the full version. Easy enough to fix.


Reply to this email directly or view it on GitHub:
#658 (comment)

@skurfer
Copy link
Member Author

@skurfer skurfer commented Jan 25, 2012

Somebody wasn't paying enough attention to the 'final releases’ section here: http://qsapp.com/wiki/Release_Process

Hey, come on. It’s been several hours since I went over that page. :-)

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Feb 2, 2012

Poke @HenningJ - could you just confirm that you can run Python-Markdown on 10.6? Trying to build a release .app should do the trick.

All else looks good.

@HenningJ
Copy link
Contributor

@HenningJ HenningJ commented Feb 2, 2012

Yeah, just built QS release with this branch. Works fine on 10.6

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Feb 2, 2012

Great, thanks Henning :)
One small thing: when I build this, git says that loads of the files in /Tools/python-support have changed.
Here's what comes up in the git diff (for all the files)

Binary files a/Quicksilver/Tools/python-support/markdown/odict.pyc and b/Quicksilver/Tools/python-support/markdown/odict.pyc differ

and for git status

#   modified:   Quicksilver/SharedSupport/Changes.html
#   modified:   Quicksilver/SharedSupport/ChangesBare.html
#   modified:   Quicksilver/Tools/python-support/markdown/__init__.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/blockparser.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/blockprocessors.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/etree_loader.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/extensions/__init__.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/extensions/abbr.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/extensions/attr_list.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/extensions/codehilite.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/extensions/def_list.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/extensions/extra.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/extensions/fenced_code.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/extensions/footnotes.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/extensions/smart_strong.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/extensions/tables.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/inlinepatterns.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/odict.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/postprocessors.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/preprocessors.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/serializers.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/treeprocessors.pyc
#   modified:   Quicksilver/Tools/python-support/markdown/util.pyc

@HenningJ
Copy link
Contributor

@HenningJ HenningJ commented Feb 3, 2012

.pyc are compiled python files. They are created when you run a python script. I think they should be added to .gitignore (something like *.pyc)

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Feb 3, 2012

I was guessing they were something like that. In that case: Rob, can you
remove them from the repo and add them to the .gitignore?

On 3 February 2012 07:57, Henning Jungkurth <
reply@reply.github.com

wrote:

.pyc are compiled python files. They are created when you run a python
script. I think they should be added to .gitignore (something like *.pyc)


Reply to this email directly or view it on GitHub:
#658 (comment)

@skurfer
Copy link
Member Author

@skurfer skurfer commented Feb 3, 2012

Sorry, I thought I had .pyc globally ignored on my system. It should be in the local .gitignore anyway for those that don’t.

You might want to delete you copy of this branch and check it out again.

FYI, the merge conflict should just be in the generated HTML since it changed with the recent release.

@HenningJ
Copy link
Contributor

@HenningJ HenningJ commented Feb 3, 2012

BTW. do we actually want the generated .html files in the repo?
I seem to remember some rule about not keeping generated files in the repo, but only the source-files. So we would keep the markdown file and remove the .html files. They are generated on every full build anyways, right?

@skurfer
Copy link
Member Author

@skurfer skurfer commented Feb 3, 2012

BTW. do we actually want the generated .html files in the repo?

That’s a good question. My vote is “no”. Should I remove them (and add them to .gitignore) as part of this pull request?

@HenningJ
Copy link
Contributor

@HenningJ HenningJ commented Feb 3, 2012

Should I remove them (and add them to .gitignore) as part of this pull request?

Yes, that's what I was (secretly) suggesting. ;-)

BTW. my hard drive crashed this morning, so I wont be able to do any testing today. Meh. :-(

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Feb 3, 2012

. Should I remove them (and add them to .gitignore) as part of this
pull request?
Yeah I'd agree with removing them. It's annoying having to commit them
whenever we make a release. Good idea Henning

On 3 February 2012 14:43, Rob McBroom <
reply@reply.github.com

wrote:

BTW. do we actually want the generated .html files in the repo?

Thats a good question. My vote is no. Should I remove them (and add
them to .gitignore) as part of this pull request?


Reply to this email directly or view it on GitHub:
#658 (comment)

@skurfer
Copy link
Member Author

@skurfer skurfer commented Feb 3, 2012

I’ve removed and ignored them, but unlike the .pyc files, I did not remove them from the repo’s history.

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Feb 3, 2012

Looks good. Merged and committed.

@pjrobertson pjrobertson closed this Feb 3, 2012
@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Feb 3, 2012

...but for some strange reason they're not showing in the online repo, but I can pull them just fine. I've sent GH a ticket.

@skurfer
Copy link
Member Author

@skurfer skurfer commented Feb 3, 2012

I couldn’t see them either, but they just showed up. One strange thing… I ran git pull --rebase upstream master then git push which has always pushed to “origin master” but this time, I saw

Counting objects: 13, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 20.24 KiB, done.
Total 5 (delta 2), reused 3 (delta 0)
To git@github.com:quicksilver/Quicksilver.git
   2b7bebe..8fc873b  alcor -> alcor

I don’t have any local commits on that branch, so it shouldn’t hurt anything, but just a heads-up. I wonder if that somehow kicked the web interface to update.

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Feb 3, 2012

Hmmm, interesting. Seems to be working now, so looks like that did the
trick.

See #678 now this is sorted :)

On 3 February 2012 17:55, Rob McBroom <
reply@reply.github.com

wrote:

I couldnt see them either, but they just showed up. One strange thing I
ran got pull --rebase upstream master then git push which has always
pushed to origin master but this time, I saw

Counting objects: 13, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 20.24 KiB, done.
Total 5 (delta 2), reused 3 (delta 0)
To git@github.com:quicksilver/Quicksilver.git
2b7bebe..8fc873b alcor -> alcor

I dont have any local commits on that branch, so it shouldnt hurt
anything, but just a heads-up. I wonder if that somehow kicked the web
interface to update.


Reply to this email directly or view it on GitHub:
#658 (comment)

@skurfer
Copy link
Member Author

@skurfer skurfer commented Feb 3, 2012

I just remembered that the Xcode project has references to the two HTML files. Should we leave them in (since they will exist from time to time), or remove them? If you want to remove them, maybe just do it in #678 since that file will be modified anyway.

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Feb 3, 2012

Just thought about that. I think they should stay in the Xcode proj.
They'll always exist on users' computers, so Xcode should know about them,
but git doesn't.

On 3 February 2012 18:12, Rob McBroom <
reply@reply.github.com

wrote:

I just remembered that the Xcode project has references to the two HTML
files. Should we leave them in (since they will exist from time to time),
or remove them? If you want to remove them, maybe just do it in #678 since
that file will be modified anyway.


Reply to this email directly or view it on GitHub:
#658 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants