New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adapters not being expanded #121

Closed
joaocc opened this Issue Oct 6, 2017 · 7 comments

Comments

Projects
None yet
2 participants
@joaocc

joaocc commented Oct 6, 2017

This happens in the following 2 places.
In this case, we tested with same-origin adpters and it works fine.

<backup name="adapter:myEnv:BAK_NAME"...
...
      <target
        dirname="adapter:myEnv:BAK_DIR"

@sebastianfeldmann

This comment has been minimized.

Show comment
Hide comment
@sebastianfeldmann

sebastianfeldmann Oct 6, 2017

Owner

Sorry I don’t understand what you are trying to say? Can you be a bit more specific and post your adapter configuration.
What do you mean by “same-origin adapters”?

Owner

sebastianfeldmann commented Oct 6, 2017

Sorry I don’t understand what you are trying to say? Can you be a bit more specific and post your adapter configuration.
What do you mean by “same-origin adapters”?

@joaocc

This comment has been minimized.

Show comment
Hide comment
@joaocc

joaocc Oct 6, 2017

Sorry about the impromptu terminology.
I have since been able to address the shortcomings using the PHP adapter.
My original setup was a .env file and a XML config file.
Some of the variables from the .env file were correctly expanded.
But, the expansion failed at the backup/name and target/dirname locations.
Thx

joaocc commented Oct 6, 2017

Sorry about the impromptu terminology.
I have since been able to address the shortcomings using the PHP adapter.
My original setup was a .env file and a XML config file.
Some of the variables from the .env file were correctly expanded.
But, the expansion failed at the backup/name and target/dirname locations.
Thx

@sebastianfeldmann

This comment has been minimized.

Show comment
Hide comment
@sebastianfeldmann

sebastianfeldmann Oct 6, 2017

Owner

So what you are saying is, that using the .env adapter some placeholders where replaced and some not?

I checked and some values are not replaceable by an adapter value at the moment.
I will fix that.

Owner

sebastianfeldmann commented Oct 6, 2017

So what you are saying is, that using the .env adapter some placeholders where replaced and some not?

I checked and some values are not replaceable by an adapter value at the moment.
I will fix that.

@sebastianfeldmann sebastianfeldmann added bug and removed question labels Oct 6, 2017

@joaocc

This comment has been minimized.

Show comment
Hide comment
@joaocc

joaocc Oct 6, 2017

Yes, that was what I was trying to say. Thx!
Regarding the adapters themselves, I also had some difficulty understanding if they are supported in the middle of strings (something to bash "somestring${var1}someoher${var2}")

joaocc commented Oct 6, 2017

Yes, that was what I was trying to say. Thx!
Regarding the adapters themselves, I also had some difficulty understanding if they are supported in the middle of strings (something to bash "somestring${var1}someoher${var2}")

@sebastianfeldmann

This comment has been minimized.

Show comment
Hide comment
@sebastianfeldmann

sebastianfeldmann Oct 6, 2017

Owner

Currently the regex is #^adapter:([a-z0-9_\-]+):(.+)#i so it only looks at start to end.

Finding the start wouldn't be an issue but finding the end of the adapter value would be tricky.

For example "fooadapter:myadapter:barbaz" would be impossible to determine.
I would have to change the adapter syntax to "foo:adapter:myadapter:bar:baz" to make that work.

I have to think about it, and check if I can make this work without breaking backwards compability.

Owner

sebastianfeldmann commented Oct 6, 2017

Currently the regex is #^adapter:([a-z0-9_\-]+):(.+)#i so it only looks at start to end.

Finding the start wouldn't be an issue but finding the end of the adapter value would be tricky.

For example "fooadapter:myadapter:barbaz" would be impossible to determine.
I would have to change the adapter syntax to "foo:adapter:myadapter:bar:baz" to make that work.

I have to think about it, and check if I can make this work without breaking backwards compability.

@joaocc

This comment has been minimized.

Show comment
Hide comment
@joaocc

joaocc Oct 6, 2017

Alternatively, you could also support both the current syntax an a new delimited syntax such as "${....}".
Anyway I solved this using the PHP adapter, doing the concatenations there.
thx and feel free to close the bug when fixed.

joaocc commented Oct 6, 2017

Alternatively, you could also support both the current syntax an a new delimited syntax such as "${....}".
Anyway I solved this using the PHP adapter, doing the concatenations there.
thx and feel free to close the bug when fixed.

@sebastianfeldmann sebastianfeldmann self-assigned this Oct 8, 2017

@sebastianfeldmann

This comment has been minimized.

Show comment
Hide comment
@sebastianfeldmann

sebastianfeldmann Oct 8, 2017

Owner

With phpbu 5.0.7 you can use multiple adapter values in a single configuration value.
With multiple adapter values you have to use leading and trailing colons as well.

<option name="some" value=":adapter:foo:dir:/path/:adapter:foo:filename:.conf"/>
Owner

sebastianfeldmann commented Oct 8, 2017

With phpbu 5.0.7 you can use multiple adapter values in a single configuration value.
With multiple adapter values you have to use leading and trailing colons as well.

<option name="some" value=":adapter:foo:dir:/path/:adapter:foo:filename:.conf"/>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment