Yes that's a good idea and I will do it, but for now I just want to make sure that every fabfile still runs as before, and it's a symlink to a fabfile in the library dir. This is because I want to move one at a time there, and there are other scripts requiring this structure. But I found that I can just do this also and it's perfectly fine, the symlink will work and it will not complain about the relative import.. export PYTHONPATH="../config/deployment/:$PYTHONPATH" fab
2013/1/30 Peter Sanchez <[email protected]>: > Not sure if this is what you had in mind but I just make it a normal Python > package and install it either in the virtualenv or in the global Python > path. > > See: https://bitbucket.org/petersanchez/djeploy > > Peter > > > On Wed, Jan 30, 2013 at 9:14 AM, andrea crotti <[email protected]> > wrote: >> >> I have all around fabfiles which are more or less copied and pasted >> all over the place. >> So I decided to create a new structure which is something like this >> >> common.py >> fabfile_api.py >> __init__.py >> README >> tests >> variables.py >> >> And then just add some symlinks in the directories where the fabfiles >> were previously. >> The problem is that the relative imports are failing: >> from .variables import CLONE >> >> because running "fab" will run the fabfile_api as a script, thus >> making the relative imports not work. >> Any solution for this problem? >> Any other suggestions to organize your deployment scripts? >> >> _______________________________________________ >> Fab-user mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/fab-user > > _______________________________________________ Fab-user mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/fab-user
