Working directory requirement is overly restrictive

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Call program from another directory (e.g. 
'../submitTool/gcj_init_contest.py')

What is the expected output? What do you see instead?

Error is expected (mentioned in documentation that scripts must be called from 
the proper directory) -- I get an error message mentioning failure to find 
config file.  See below (additional information) for how I feel the program 
should work & reasons why.

What version of the product are you using? On what operating system?

Beta2, linux x86 (Python 2.7.1)

Please provide any additional information below.

It would be more user-friendly if we could call the scripts from within the 
source file directory (either typing in the relative path or using an alias).  
This would obviate the need to configure the source file location, and 
facilitate the submission of files from different directories corresponding to 
different contests.  The contest-id corresponding to a given source directory 
could also be stored in a specially-named config file in that directory, 
minimizing the configuration required to participate in a different contest.  

IOW contest-specific configuration should be contained in the source directory 
and located based on where the program is called from (+ an optional 
commandline parameter) while site-specific configuration should stay where it 
currently is.

I don't know Python but surely it's possible for the script to discover where 
it is located in the filesystem and thus find the 'config' directory no matter 
where it's called from?

Original issue reported on code.google.com by sumu...@gmail.com on 8 May 2011 at 4:36

[GoogleCodeExporter]

Forgot to mention: for now I'm symlinking the 'source' directory to the 
contest-specific one and it works fine, but it would still be more elegant for 
the program to support the requested behaviour.

Original comment by sumu...@gmail.com on 8 May 2011 at 4:38

[GoogleCodeExporter]

You can support that by making two changes:

- In lib/constants.py, change USER_CONFIG and CURRENT_CONFIG to point to the 
path with the configuration files. The trick is to use absolute paths instead 
of relative paths, which works nicely as long as the tool path doesn't change.

- In the user configuration file (config/user_config.py), change 
'data_directory' to point to the directory with the source code, input files 
and output files ('.' is valid).

Another option is to have a config directory inside each coding directory and 
working from the source directory, this way the configuration for each contest 
is stored separately. All depends on how you want to use the tool. The only 
real issue I found is that I need to write temporary files and I'm doing it in 
the current directory, and it fails if you don't have write access there.

I could also add options to specify the configuration files manually. Do it 
looks useful to you?

Original comment by jor...@google.com on 10 May 2011 at 2:24

• Changed state: Accepted
• Added labels: Type-Enhancement, Priority-High, Usability
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

That works, but I still think it makes more sense for the program to find its 
config files at runtime, no matter what the current directory is.  I did some 
searching (recall that I'm not too familiar with python) and the discussion at 
http://www.artima.com/forums//flat.jsp?forum=181&thread=16713 seems to provide 
a couple of ways this could be done.  I don't know if those solutions are 
portable.

The basic idea behind my request is that it should be easy to use the tool to 
submit files from any directory; the most natural way to use it is to submit 
files in the current (source) directory, instead of requiring changes to 
configuration files each time we want to change that.

Regarding the config directory, I didn't really think about the issues 
surrounding logging in and out, which complicates matters.  I'm not totally 
sure what the best way is but I think the way it works now is OK, we just have 
to remember to call gcj_init_contest before doing anything.

Anyway thanks for developing this!  Despite my small gripe, I do think it's 
well designed / built overall, and certainly makes submitting solutions less 
clunky.

Original comment by sumu...@gmail.com on 10 May 2011 at 10:18

[GoogleCodeExporter]

The problem I see is that the current way is more flexible than forcing the 
tool to read from a single place, and using absolute paths allows you to read 
from the same place independently of the current directory.

However, what about making the paths in lib/constants.py parametrizables? For 
example, by doing "USER_CONFIG = '{base_dir}/config/user_config.py'" the tool 
automatically substitutes {base_dir} by the directory where the gcj_* scripts 
are. That way it's flexible and can be changed to depend on the "installation 
directory" instead of the current directory.

Logging in and out is an issue, specially because the cookie expires in one 
day. However, all scripts automatically update it if they find it expired, so 
you should be able to download and submit using a stale current_config.py.

You're welcome! Right now I'm working on fixing the issues added here and 
adding some additional functionality.

Original comment by jor...@google.com on 11 May 2011 at 1:04

[GoogleCodeExporter]

And by the way, thanks for the link.

Original comment by jor...@google.com on 11 May 2011 at 1:08

[GoogleCodeExporter]

Some changes are being done to the tool:

- Added a base_dir variable used to parametrize config files paths. It's the 
directory where the gcj_* are, but it can be changed by an option. This should 
make easier the usage of an absolute path, which allows the tool to run from 
any directory.

- All network traffic and source zipping/unzipping is done in memory-mapped 
files, so there is no need to use temporary files in the current directory.

Original comment by jor...@google.com on 11 May 2011 at 11:11

• Changed state: Started

[GoogleCodeExporter]

These changes were uploaded to the svn repository, you can download a new 
version from it and test if everything works nicely.

Original comment by jor...@google.com on 12 May 2011 at 6:38

• Changed state: Fixed

[GoogleCodeExporter]

Sorry, didn't get around to looking at this for a while.

The base_dir variable is a good solution.

I would suggest using os.path.realname(__file__) (instead of just __file__) 
when resolving it, because that handles symlinks nicely (e.g. if I put a 
symlink to the python script in my /bin directory).

Original comment by sumu...@gmail.com on 21 May 2011 at 6:21

[GoogleCodeExporter]

(that should have said "realpath" instead of "realname")

Original comment by sumu...@gmail.com on 21 May 2011 at 6:23

[GoogleCodeExporter]

I'm reopening to address this in the next version.

Original comment by jor...@google.com on 21 May 2011 at 4:38

• Changed state: Started

[GoogleCodeExporter]

Changed it to os.path.dirname(os.path.realpath(__file__)) and it worked fine. 
This should be available in the next release before Round 2.

Original comment by jor...@google.com on 24 May 2011 at 10:35

[GoogleCodeExporter]

Original comment by jor...@google.com on 3 Jun 2011 at 4:06

• Changed state: Fixed