I am writing a Greasemonkey script, how to implement auto updating?
Is possible put script into GitHub repository and set #version number?
And then... is some automatically way how to do it? Or I must manually check.
As of some time ago, Greasemonkey supports auto updates (it was not the case at the moment the question was asked):
Add #updateURL to the script meta config. It can (but not necessary) be the same as #downloadURL.
Add #version to meta. Each new script version should increment the value.
Optionally, the file name should end with .user.js for GM to open the installation dialog.
Is possible put script into GitHub repository and set #version number?
The script can be hosted in GitHub repo or gist. The download and update URLs should link to the raw file, though. To install the script, user will have to open that #downloadURL. Here's the GM wiki page on the subject.
Related
I run this command in the terminal to pull my theme files from Shopify to my local development environment.
theme get –password=your-api-password –store=your-store.myshopify.com –themeid=your-theme-id
Usually, this command works fine but I got a message on the terminal and I'm not sure what the next step is, it's not listed in any documentation. The message is:
Available theme versions:
[116161183899][live] Debut
What's the next command to download this actual theme?
you should add --list on the command you write, this is not an error, theme get --list --password=... --store=... give you the list of all templates installed on your site. Your msg says you have one.
after that, you have two options use the commands get or download. I recommend you use get, because it will set a config file to easy use all the commands on the future, more info here with get the command the first time should be:
theme get --password=... --store=... --themeid=...
After that it will download the theme and create a config file on the root of the project. you can use this config file on the future with any command.
theme get --env=development
the config file is very useful, you can set multiple enviroments, more details here
If this not fix your issue please send the version themekit version and OS you use.
When I am editing a standalone Python file in VSCode (not part of a workspace) I will often need to alter the value of python.pythonPath to reflect a specific virtualenv I am using to run that code.
As the setting is just for the one file, I don't want to change my persistent global settings, and I don't have workspace settings. Is there a way to change a setting just for this session? (Ideally, just for this one file, but I don't expect that to be possible, so I'd be happy with "just for the session"). If there isn't a built in way to do this, is there an extension which allows this? Or even an extension API that I could use to write my own extension for this?
As an alternative, is there a way to use an environment variable in a setting, and then set that environment variable for the current VSCode process? That would have the same effect, it would just require me to set up my user settings specifically to allow this usage.
If you launch vscode from the terminal after having activated your virtualenv, vscode will automatically use the aforementioned virtualenv (with no modification to your settings):
Exemple:
source venv/bin/activate
code .
Note: if vscode is already opened, use code -n . in order to open the file/folder in a new window.
I am currently working with a coding project using the bzr (bazaar) source code management software. I would like to include the version number in the file code of my project
So that I could call the variable "VERSION" and echo out my current working version.
Within the code be able to do this:
var VERSION = ###;
Where ### is the current version number. Is this possible? or do I have to inspect the bzr info on a file and increment my version manually prior to committing new code?
The only solution I know is the Keyword plugin for Bazaar:
http://doc.bazaar.canonical.com/plugins/en/keywords-plugin.html
(This points to https://launchpad.net/bzr-keywords but the first link has more explanation).
Steps:
Get the plugin
bzr branch lp:bzr-keywords
Install plugin (basically copy it in bazaar plugins install folder)
Get the help
bzr help keywords
Once installed, commit your code with the keywords inside, it will be replaced.
Another option is to invoke the 'bzr version-info' command, which can output the version number in various convenient ways.
I just created my first trac project, but I don't want the sample data, how can I disable that.
I read the documentation and there is the wiki remove command. do I have to use this for all pages? Are there easy way to disable the sample wiki?
Modification of the behavior of
trac-admin <path_to_env> initenv seems not even worth the hassle, because you only need to type
trac-admin <path_to_env> wiki remove '*'
into a system terminal to get rid of all default Trac wiki pages. You'll see a list of all deleted page names for confirmation. But you always make a db copy before messing with the db anyway, don't you?
Sorry but there is no easy way to diable the sample wiki in trac. I'm pretty sure this can be done with a custom script, though.
Trac stores the default pages imported into the wiki of a new environment as plaintext files in the file system.
For example, on my Gentoo box they can be found in /usr/lib64/python2.7/site-packages/trac/wiki/default-pages/.
You can move these out of the way (or just keep those you want) before calling trac-admin projectname initenv and it will only create the pages that are in the ´default-pages` directory at the time of the call.
I am working on a small toy project who is getting more and more releases. Until now, the documentation was just a set of pages in the wordpress blog I setup for the project. However, as time passes, new releases are out and I should update the online documentation to match the most recent release.
Unfortunately, if I do so, the docs for the previous releases will "disappear" as my doc pages are updated to the most recent version, therefore I decided to include the documentation in the release package and to keep the most recent documentation available online as a web page as well.
A trivial idea would be to wget the current docs from the wordpress pages, save them into the svn and therefore into the release package, repeating the procedure at every new release. Unfortunately, the HTML I get must be hacked by hand to fix the links (or I should hack wordpress to use BASE so that the HTML code is easily relocatable, something I don't want to do).
How should I handle the requirements of having at the same time:
user-browsable documentation for the proper version included in the downloadable package
most recent documentation available online (and properly styled with my web theme)
keep synchronized between the svn and the actual online contents (in wordpress, or something else that fits nicely with my wordpress setup)
easy to use
Thanks
Edit: started a bounty to see if I can lure more answers. I think this is a quite important issue, and it would be nice to have multiple hints and opinions for future readers.
I would check your pages into SVN, and then have your webserver update from its local SVN working copy when you're ready to release. Put everything into SVN--wordpress, CSS, HTML, etc.
WGet can convert all the links in the document for you. See the convert-links option:
http://www.gnu.org/software/wget/manual/html_node/Advanced-Usage.html
Using this in conjuction with the other methods could yield a solution.
I think there are two problems to be solved here
how and where to keep the documentation aligned with the code
where to publish the documentation
For 1 i think it's best to:
keep the documentation in a repository (SVN or git or whatever you already use for the code) as a set of files, instead of in a db as it is easier to keep a history of changes (an possibly to stay in par with the code releases
use an approach where the documentation is generated from a set of source files (you'd keep the sources in the repository) from which the html files for the distribution package or for publishing on the web are generated. The two could possibly differ, as on the web you'd need to keep some version information (in the URL) that you don't need when packaging a single release.
To do "2" there are several tools that may generate a static site. One of them is Jekyll it's in ruby and looks quite complete and customizable.
Assuming that you use a tool like jekyll and keep the files and source in SVN you might setup your repo in this way:
repo/
tags/
rel1.0/
source/
documentation/
rel2.0/
source/
documentation/
rel3.0/
source/
documentation/
trunk/
source/
documentation/
That is:
You keep the current documentation beside the source in the trunk
When you do a release you create a tag for the release
you configure your documentation generator to generate documentation for each of the repo/tags//documentation directory such that the documentation for each release is put in documentation_site/ directory
So to publish the documentation (point 2 above):
you copy on the server the contents of the documentation_site directory, putting it in the same base dir of your wordpress install or linking from that, such that each release doc can be accessed as: http://yoursite/project/docs/relXX/
you create a link to the current release documentation such that it can always be reached as http://yoursite/project/docs/current
The trick here is to publish the documentation always under a proper release identifier (in the URL, on the filesystem) and use a link (or a redirect) to make sure that the "current documentation" on the web server points to the current release.
I have seen some programs use help & manual. But I am a Mac user and I have no experience with it to know if it's any good. I'm looking for a solution myself for Mac.
For my own projects, if that were a need, I would create a sub-dir for the documentation, and have all the files refer from the known-base of there relatively. For example,
index.html -- refers to images/example.jpg
README
-- subdirs....
images/example.jpg
section/index.html -- links back to '../index.html',
-- refers to ../images/example.jpg
If the docs are included in the SVN/tarball download, then they are readable as-is. If they are generated from some original files, they would be pre-generated for a downloadable version.
Archive versions of the documentation can be unpacked/generated and placed into named directorys (eg docs/v1.05/)
Its a simple PHP script that can be written to get a list the subdirs of the /docs/ directory from the local disk and display a list, and highlighting the most recent, for example.