buildout
buildout copied to clipboard
Allow ~ expansion for develop=
Given:
develop = ~/scripting/packages/mytool
I want to be able to use ~ expansion here. Using different user directories with git revision control breaks the current implementation of specifying the user dir. Why can't ~ be expanded in buildout.cfg ?
Do you know you can use ${buildout:directory}
?
That's an initialization directory. I am running bin/buildout from another location than where the develop dir is. ${buildout:directory} seems to just point to the directory buildout is being built in. I want to reference ~ so that on any git clone of our toolset, It will point to the setup.py in our git controlled folder. We can't push this to pypi, it's internal use only.
+1 for honoring ~
in develop and everywhere else that buildout gets paths from users.
@mdeguzis Maybe this could be a feature for the fs
mode of mr.developer.
@icemac is there any case where one would not want to expand ~
at the front of a user-supplied path?
@jimfulton Not out of my head. (I did not see your +1 comment before writing mine and I did not expect that you might up-vote so I proposed a different solution.) I am fine with expanding ~
inside buildout itself.
I saw in some other user's example configs, that 'HOME' is used. Is this another way to specify the user's $HOME ?
@mdeguzis there is recipes that can provide you with functionality that you want, for example with https://pypi.python.org/pypi/gocept.recipe.env/ you can do following:
[buildout]
parts += ... env
develop = ${env:HOME}/path/to/mytool/setup.py
[env]
recipe = gocept.recipe.env
But it doesn't seem right. I would recommend to make distribution from mytool
and set a path to it in buildout find-links
option, and if this is private repo under some SVC that is located on remote server you can add that distribution binary to SVC and put link with credentials to find-links
. Alternatively if mytool
is under development itself, it would be more efficient to use mr.developer
@jimfulton the downside of approach of replacing ~
with userpath
everywhere is that it could make managing some special tokens with zc.buildout I way more worse. Adding "a silent ~ token modification"
to "token ${ that breaks buildout }"
sounds like total nightmare to me (as far as I remember there is no way to escape construction ${...}
in buildout).
I would be more in favor of having all replacements only inside ${...}
with escaping mechanism (something like is done for python format string syntax), I guess it could make tool itself more consistent and easy to maintain.
@enkidulan I don't understand. My thought was that at the point that buildout actually opens a file, it would do ~ expansion. This would be long after variable substitutions have been applied.
Does that address your concern? If not, could you give a more specific example of what you're worried about?
Right now, I think buildout violates user's expectations by not expanding ~.
BTW, I think this would be a good sprint topic, as it doesn't require much knowledge of the buildout code.
As I said in the other ticket, there is code that calls os.path.expanduser()
. I don't know why it apparently doesn't work anymore.
https://github.com/buildout/buildout/blob/master/src/zc/buildout/buildout.py#L412
I've added proposal with alternative solution for referring user's home path https://github.com/buildout/buildout/issues/391
While I support making environment variables easier to leverage, I don't see that as an alternative to meeting peoples' expectations re ~ :)
@enkidulan you are adamant that honoring ~ at the beginning of a path when opening files will cause breakage. I don't understand why this would be the case. Can you give a specific scenario? The only one I can imagine is if someone names a directory ~ and then wants to refer to it, which seems wildly unlikely.
Besides, people can always use ./~ to refer to local directories named ~.
I agree with @jimfulton os.path.expanduser
will only expand ~
if the path starts with it so when loading just these cache paths.