A colleague of mine implement a shell script with the following line
output="$(venv/bin/python manage.py has_missing_migrations --quiet --settings=project.tests_settings 2>&1)"
Here is the full code :
# Check missing migrations
output="$(venv/bin/python manage.py has_missing_migrations --quiet --settings=project.tests_settings 2>&1)"
[ $? -ne 0 ] \
&& ipoopoomypants "Migrations" "$output" \
|| irock "Migrations"
If I run the script, I obtain
Running pre-commit checks:
[OK] anonymize_db ORM queries
[OK] Forbidden Python keywords
[OK] Forbidden JavaScript keywords
[OK] Forbidden HTML keywords
[FAIL] Migrations
COMMIT REJECTED: .git/hooks/pre-commit: line 88: venv/bin/python: No such file or directory
The problem with the above line is it takes into account that the virtual environment has been created inside the project itself. However, it is not always the case. From what I am concerned, I work with virtualenvwrapper. Hence, my virtualenv is not ./venv, but well in ~/.virtualenvs/venv.
Question : How could I modify the above line in such a way it will consider both path ./venv and ~/.virtualenvs/venv?
You should probably use the WORKON_HOME environment variable to point the the location of virtualenvs instead of hard-coding it.
Related
I am writing a Dockerfile. Is there a way to make comments in this file?
Does Docker have a comment option that takes the rest of a line and ignores it?
You can use # at the beginning of a line to start a comment (whitespaces before # are allowed):
# do some stuff
RUN apt-get update \
# install some packages
&& apt-get install -y cron
#'s in the middle of a string are passed to the command itself, e.g.:
RUN echo 'we are running some # of cool things'
As others have mentioned, comments are referenced with a # and are documented here. However, unlike some languages, the # must be at the beginning of the line. If they occur part way through the line, they are interpreted as an argument and may result in unexpected behavior.
# This is a comment
COPY test_dir target_dir # This is not a comment, it is an argument to COPY
RUN echo hello world # This is an argument to RUN but the shell may ignore it
It should also be noted that parser directives have recently been added to the Dockerfile which have the same syntax as a comment. They need to appear at the top of the file, before any other comments or commands. Originally, this directive was added for changing the escape character to support Windows:
# escape=`
FROM microsoft/nanoserver
COPY testfile.txt c:\
RUN dir c:\
The first line, while it appears to be a comment, is a parser directive to change the escape character to a backtick so that the COPY and RUN commands can use the backslash in the path. A parser directive is also used with BuildKit to change the frontend parser with a syntax line. See the experimental syntax for more details on how this is being used in practice.
With a multi-line command, the commented lines are ignored, but you need to comment out every line individually:
$ cat Dockerfile
FROM busybox:latest
RUN echo first command \
# && echo second command disabled \
&& echo third command
$ docker build .
Sending build context to Docker daemon 23.04kB
Step 1/2 : FROM busybox:latest
---> 59788edf1f3e
Step 2/2 : RUN echo first command && echo third command
---> Running in b1177e7b563d
first command
third command
Removing intermediate container b1177e7b563d
---> 5442cfe321ac
Successfully built 5442cfe321ac
Use the # syntax for comments
From: https://docs.docker.com/engine/reference/builder/#format
# My comment here
RUN echo 'we are running some cool things'
Dockerfile comments start with #, just like Python.
kstaken has good examples:
# Install a more-up-to date version of MongoDB than what is included in the default Ubuntu repositories.
FROM ubuntu
MAINTAINER Kimbro Staken
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10
RUN echo "deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen" | tee -a /etc/apt/sources.list.d/10gen.list
RUN apt-get update
RUN apt-get -y install apt-utils
RUN apt-get -y install mongodb-10gen
#RUN echo "" >> /etc/mongodb.conf
CMD ["/usr/bin/mongod", "--config", "/etc/mongodb.conf"]
Docker treats lines that begin with # as a comment, unless the
line is a valid parser directive. A # marker anywhere else in a line
is treated as an argument.
example code:
# this line is a comment
RUN echo 'we are running some # of cool things'
Output:
we are running some # of cool things
Format
Here is the format of the Dockerfile:
We can use # for commenting purpose, as for example #COMMENT
#FROM microsoft/aspnetcore
FROM microsoft/dotnet
COPY /publish /app
WORKDIR /app
ENTRYPOINT ["dotnet", "WebApp.dll"]
From the above file when we build the docker, it skips the first line and goes to the next line because we have commented it using #
# this is comment
this isn't comment
is the way to do it. You can place it anywhere in the line and anything that comes later will be ignored
I have a recipe below (migrate.rb) which is run as part of our deployment and works perfectly.
However one thing that I can't workout is how to set it up so it can also be run as a standalone recipe in the execute_recipe command.
As it stands if we execute this recipe as a stand alone then nothing happens since the node[:deploy].each has nothing to loop over (the deploy key doesn't exist)..
The only part that actually relies on the deploy node is this line cwd "#{deploy[:deploy_to]}/current" since I need to know where the code was deployed to.
node[:deploy].each do |application, deploy|
execute 'DB migrate then seed' do
cwd "#{deploy[:deploy_to]}/current"
command 'php artisan migrate; while read -r line || [ -n "$line" ]; do php artisan db:seed --class="$line"; done < "app/database/run.list"'
end
end
I would relocate that part to a definition (or a provider). So basically split your recipe in two parts:
recipes/deploy.rb:
node[:deploy].each do |application, deploy|
php_artisan_setup do
dir "#{deploy[:deploy_to]}/current"
end
end
definitions/php_artisan_setup.rb:
define :php_artisan_setup do
execute 'DB migrate then seed' do
cwd params[:dir]
command 'php artisan migrate; while read -r line || [ -n "$line" ]; do php artisan db:seed --class="$line"; done < "app/database/run.list"'
end
end
This way, you can call php_artisan_setup from your "standalone" recipe, too. You still need two recipes, but you dont have to duplicate the relevant part.
I have a (maybe) unusual situation. I need to run VMware CLI commands in a Windows box, but via the cygwin CLI inside a shell script. I can NOT change this for now, so any suggestions to "why not do this instead" may be futile, although appreciated. Here's a sample script.
#!/bin/bash
# Paths for vmware-cmd.pl file to run vmware commands from vsphere cli
_vcli_dir="/cygdrive/c/Program Files (x86)/VMware/VMware vSphere CLI"
_vcli_bin="$_vcli_dir/bin"
_vcli_perl="$_vcli_dir/Perl"
_vcli_perl_bin="$_vcli_perl/bin"
_vcli_perl_lib="$_vcli_perl/lib"
_vcli_perl_vlib="$_vcli_perl_lib/VMware"
_vcmd=vmware-cmd.pl
export _orig_path=$PATH
# Add above directories to path variable
export PATH=$PATH:$_vcli_dir:$_vcli_bin:$_vcli_perl:$_vcli_perl_bin:$_vcli_perl_lib:$_vcli_perl_vlib
echo $PATH
$_vcmd /?
export PATH=$_orig_path
echo $PATH
When I run the above script, I get
Can't locate VMware/VIRuntime.pm in #INC (#INC contains:
/usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int
/usr/lib/perl5/site_perl/5.14
/usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int
/usr/lib/perl5/vendor_perl/5.14
/usr/lib/perl5/5.14/i686-cygwin-threads-64int /usr/lib/perl5/5.14
/usr/lib/perl5/site_perl/5.10 /usr/lib/perl5/vendor_perl/5.10
/usr/lib/perl5/site_perl/5.8 .) at /cygdrive/c/Program Files
(x86)/VMware/VMware vSphere CLI/bin/vmware-cmd.pl line 8. BEGIN
failed--compilation aborted at /cygdrive/c/Program Files
(x86)/VMware/VMware vSphere CLI/bin/vmware-cmd.pl line 8.
I can run the same vmware-cmd.pl script from a DOS command prompt
c:> vmware-cm.pl
So I now my installation is correct.
Any clues please?
This post gave me the idea to fix it. But now I get a core dump.
How is Perl's #INC constructed? (aka What are all the ways of affecting where Perl modules are searched for?)
The added line is the second export PERL5LIB line.
#!/bin/bash
# Path for vmware-cmd.pl file to run vmware commands from vsphere cli
_vcli_dir="/cygdrive/c/Program Files (x86)/VMware/VMware vSphere CLI"
_vcli_bin="$_vcli_dir/bin"
_vcli_perl="$_vcli_dir/Perl"
_vcli_perl_bin="$_vcli_perl/bin"
_vcli_perl_lib="$_vcli_perl/lib"
_vcli_perl_vlib="$_vcli_perl_lib/VMware"
_vcmd=vmware-cmd.pl
export _orig_path=$PATH
# Add above directories to path variable
export PATH=$PATH:$_vcli_dir:$_vcli_bin:$_vcli_perl:$_vcli_perl_bin:$_vcli_perl_lib:$_vcli_perl_vlib
export PERL5LIB=$_vcli_dir:$_vcli_bin:$_vcli_perl:$_vcli_perl_bin:$_vcli_perl_lib:$_vcli_perl_vlib
echo $PATH
$_vcmd /?
export PATH=$_orig_path
echo $PATH
I solved by going through my elbow to get to my a**, as the saying goes.
What I did was
- Install vmware cli on my Windows box to the default directory
- Added environment variables for the VMware main directory, the bin directory, the Perl directory and the Perl/bin directory
- Added these environment variables to my PATH variable.
Then I created a vmware-cli.bat file that takes parameters and concatenates them into a vmware-cli command with the correct values. For example, I call this to list the VMs in the server
cygwin:> ./vmware-cli.bat vmware-cmd.pl --server MyServer --username User --password PW -l
Inside the batch file I essentailly do
REM Get first parm as the command, and then concatenate the rest of the parms
set VCLI_CMD=%1
shift
:LOOP
if %1x==x goto :EXECUTE
set VCLI_CMD=%VCLI_CMD% %1
shift
goto LOOP:
:EXECUTE
%VCLI_CMD%
This is an alternative to the previous posted that will allow you to keep it in the same shell script
VIMCMD="/cygdrive/C/Program Files (x86)/VMware/VMware vSphere CLI/bin/vmware-cmd.pl"
VIMCMD_DOS=$(cygpath -d "$VIMCMD")
DOS_VIMCMD="cmd /c $VIMCMD_DOS"
Then you can run:
$ $DOS_VIMCMD --version
vSphere SDK for Perl version: 6.0.0
Script 'vmware-cmd.pl' version: 6.0.0
I have just installed South (0.7.3, python-2.6) and successfully completed the tutorial using the python interpreter. Meaning that I am able to create a model and migrate it without any errors, so South appears to be working fine in the python shell. I used an sqlite3 db for the tutorial.
However, when I open my project in Eclipse, Eclipse does not recognize the functions associated with db in the migration folders: 0001_initial.py and 0002_auto__add_field_knight_dances_whenever_able.py files. I get the specific errors ( Undefined variable from import: add_column, create_table, delete_column, delete_table, send_create_signal)
Up until the South install, Eclipse has been working fine for creating django apps. I did point the PyDev interpreter to the south folder under site-packages (C:\python26\Lib\site-packages\south-0.7.3-py2.6.egg) (Other libraries there such as Django and django-picklefield work fine.)
I ran a simple script from the eclipse project and from the python shell and both appear to have the same sys.path's
Any tips on getting the Eclipse python interpreter happier?
Or, if you don't want to mess changing south source files or retouching all your migration files, you can consider south specific methods as globals in pydev code analysis.
You can change this in:
Preferences > PyDev > Editor > Code Analysis > Undefined
My exceptions list are:
_,tr,create_table,send_create_signal,delete_table,add_column,delete_column,alter_column,create_unique,create_index,delete_index,delete_unique,shorten_name,rename_column,execute
One (far from ideal) solution is to put ##PydevCodeAnalysisIgnore in all of your migrations. If you only have a few so far, you can do this manually. I had heaps, so I ran the following shell command, which will add the comment in as the second line of each file:
find . | grep '^.\/[a-z]*\/migrations\/.*\.py$' | xargs -I FILE sed -i '
1 a\
##PydevCodeAnalysisIgnore
' FILE
(Note: You should probably run find . | grep '^.\/[a-z]*\/migrations\/.*\.py$' to see which files sed will alter, before running the whole command. You can also run the whole command without the -i flag to see the changes themselves.)
Here's a workaround if you want to edit south/db/__init__.py:
--- db/__init__.py.original 2010-12-02 03:00:26.000000000 +1300
+++ db/__init__.py 2011-05-02 14:07:19.353636710 +1200
## -72,5 +72,9 ##
)
sys.exit(1)
-# Finally, to make old migrations work, keep 'db' around as the default database
+# Finally, to make old migrations work, keep 'db' around as the default
+# database. We're setting it explicitly to the generic operations first to
+# avoid pydev errors.
+from south.db import generic
+db = generic.DatabaseOperations(DEFAULT_DB_ALIAS)
db = dbs[DEFAULT_DB_ALIAS]
I have just spotted that something is wrong with my django-admin.py command. I checked similar SO posts on django-admin.py problems but nothing seems to be related to my problem. I use Windows Vista (yeah, I know...). I also have many versions of django in some folder on my disk and I switch to the version I need using junction command (this is similar to symlinking in unix), I don't have problems with this and never had problems before.
I used django-admin.py many times before but now for some unknown reasons I got this info (Django 1.1.1):
C:\>django-admin.py startproject some_project
Type 'django-admin.py help' for usage.
and suprisingly when I type what django asked me to type:
C:\>django-admin.py help
Type 'django-admin.py help' for usage.
????
When I switch to Django 1.2.1 I got this:
C:\>django-admin.py startproject help
Usage: django-admin.py subcommand [options] [args]
Options:
-v VERBOSITY, --verbosity=VERBOSITY
Verbosity level; 0=minimal output, 1=normal output,
2=all output
--settings=SETTINGS The Python path to a settings module, e.g.
"myproject.settings.main". If this isn't provided, the
DJANGO_SETTINGS_MODULE environment variable will be
used.
--pythonpath=PYTHONPATH
A directory to add to the Python path, e.g.
"/home/djangoprojects/myproject".
--traceback Print traceback on exception
--version show program's version number and exit
-h, --help show this help message and exit
Type 'django-admin.py help <subcommand>' for help on a specific subcommand.
Available subcommands:
cleanup
compilemessages
createcachetable
...
startproject
...
validate
no matter if I type startproject help or startproject some_name it always shows the same message.
Any ideas?
EDIT: new info
I've just noticed that my command line arguments are not visible when command is parsed by django managament utlity (when I print command argv it shows only path to django-admin.py without any of given arguments)
The problem in my case was the I've lost .py file association rules.
If you have similar problem you can check in command line what is the result of:
assoc .py
If there is no such association you need to create it:
assoc .py=Python.File
and create rule for Python.File:
ftype Python.File="c:\python27\python.exe" "%1" %*
(Replace with whatever the path is to your python interpretter.)
now django-admin.py accepts command line args and everything works fine!
This would be better as it does not require touching the registry at all:
https://stackoverflow.com/a/10732170/1585863