Feature proposal: saving current request setup under named alias

[fogine]

This is great package, thanks for sharing your work!

As I've been using it couple of days I noticed that it's quite inconvenient, having to repeatedly change request settings every time I want to send different request.
The option of saving current state of request would solve the problem.

Given this output of httpie post:

http://127.0.0.1:3000/api/oauth/token> http --form --style native POST http://127.0.0.1:3000/api/oauth/token user_id==value client_id=value client_secret=value grant_type=password password=test  username=testuser1 Content-Type:application/x-www-form-urlencoded

We could use eg.: http://127.0.0.1:3000/api/oauth/token> alias getToken

which would save the request under getToken keyword. Later, we could call getToken request and optionally overwrite any req options like so:

http://127.0.0.1:3000/api/oauth/token> getToken username=testuser2 password=test2

[eliangcs]

I like your idea of saving a state, but I think the user interface could be better. This tool tries hard to mimic the Unix/Linux shell environment, but alias getToken does not look like one. Perhaps we should approach this with Unix pipelines:

# Print the current state
http://127.0.0.1> env
username==testuser
password==testpassword

# Export the current state to a file
http://127.0.0.1> env > state.txt

# Import state from a file
http://127.0.0.1> source state.txt

[fogine]

You're right @eliangcs , that would be even better.

[fogine]

I've started working on the unix pipelines feature as well as env and source commands.
HERE is the current state of development.

What's been done:

• Redirecting command output to files write & append operations aka. > & >>
  • This currently works for env, preview and action commands
  • Eg.: env > /tmp/env.log

  •     `httpie post some=data > /tmp/httpie.log`
    

• env command
• some tests

What needs to be done:

• source command
• exec command
• tests for redirecting of command output to file
• what should be the filepath relative to when redirecting command output? (if relative path is provided)
• we need to decide how the env command should behave (the explanation bellow)
• support of concurrent logging of command output to a console & writing output data to a file
  • Eg.: post bar=baz | tee /tmp/reqdump

The dilemma I'm facing now is how should I implement the env command - It quite makes sense to output only request data & headers when we are echoing a command output to a terminal, however when we redirect the output of the env command to a file, we need to write all context data - that means the exact same data which are currently saved for example to $HOME/.local/share/http-prompt/context/localhost.80.
So, because of that I think the output of the env command should contain always all context data, no matter if we echo to a console or write to a file.

May I ask for some feedback @eliangcs , please?

[eliangcs]

@fogine Thank you very much for taking the effort to do this! I think when a user does source file, http-prompt should execute the file content line by line, just as you were to enter those lines manually. So for example, you have a file named ./abc.txt:

cd http://example.com
name=abc
query==foo
Content-Type:application/json

When a user does source ./abc.txt, the result should be equivalent to what happens when you enter these commands:

http://localhost> cd http://example.com
http://example.com> name=abc
http://example.com> query==foo
http://example.com> Content-Type:application/json

I agree we should output all context data, no matter we're writing to a terminal or a file. So if a user does env, it should print not only request headers and data, but also a cd to the current URL, such as:

http://example.com> env
cd http://example.com
name=abc
query==foo
Content-Type:application/json

Does it make sense?

[fogine]

@eliangcs , you provided excellent contribution guide and therefore eased the process of starting out for me, thanks!

The way how you described the env & source command should work makes totally sense. However I have few more related points I'd like to discuss with you:

• The current source command concept does not count with the context (aka. state) switching but rather polluting of the current state of the http-prompt console... which is totally correct for the command named source. However, we also need a functionality which would allow as to quickly switch to completely different context without the need of executing rm * command.
  Consider the following example:

contents of ./abc.txt file:

cd http://someurl.com
name=abc
query==foo

the http-prompt console:

http://localhost> env
cd http://localhost
bar=baz

http://localhost> source ./abc.txt
http://someurl.com> env
cd http://someurl.com
name=abc
query==foo
bar=baz         # !!! we would have to execute `rm *` before the `source` command so that the `bar` parameter wouldn't have been included... which is cool but a man gets bored quickly of having to type too much :) 

that's why we should consider introducing another command exec alongside the source command.
Only difference would be that the exec would clear current state before executing contents of ./abc.txt file (that way it would reflect the behavior of bash version of the exec command). What is your opinion about that?

---

• Another thing I'm not sure about is when command output is redirected to file and we got relative path to a file, then what should be the filepath relative to?
  When we do eg.: env > ./some/relative/path/to/file...
  My suggestions are either $HOME or XDG Base Directory (~/.local/share/http-prompt)

[eliangcs]

@fogine I think exec is a great idea! A user can use source to override context partially, while exec can be used to replace the current context with a new one.

The file path should be relative to the current working directory. When we have shell command support (WIP in #61), we can do something cool like:

> value=="a very long string"
> env > ./out.txt

# Compute sha1 hash of 'value' in shell, and assign back to querystring parameter 'value_sha1'
> value_sha1==`cat ./out.txt | grep value | sed "s/^value==//g" | sha1sum`

[fogine]

As I've been implementing the exec & source commands. I've stumbled upon an issue with event listener for the url_changed event. This is causing unexpected loading of saved context data from the $HOME/.local/share/http-prompt/context/localhost.80 file every time a cd command is executed from the sourced file.
I could overcome this somehow, however I think that the functionality of loading saved context on a base url change won't be needed anymore. The feature can be replaced by the env & source & exec commands...
This is how we could alter the behavior of automatic context saving:
Automatically saved context data would be always saved to the single $HOME/.local/share/http-prompt/context file and only on the http-prompt exit.

Any thoughts about the issue, @eliangcs ?
Thanks!

[eliangcs]

@fogine I agree with you. Automatic context saving should happen only when http-prompt exits. Feel free to alter this behavior. Thanks!

[fogine]

@eliangcs , I've updated the list HERE so it reflects current state of the development. All discussed features have been implemented (with additional output redirection option eg.: httpie post | tee /tmp/httpie.log ... which logs to the console and writes to provided file).
The automatic context saving feature has been altered so it saves only the current environment to the single file.
The only thing which is not done yet are tests (will come shortly...).
Also, there are the lexer definitions I struggle with, particularly with preview | action commands integration:

httpie post someurl | tee /tmp/test # is highlighted as incorrect
httpie post bar=baz > /tmp/test # is highlighted as incorrect
post > /tmp/test # is also highlighted as incorrect

I made few attempts which I expected to work (but they didn't)...
Would you have a time to look at the lexer definitions, please?

[fogine]

The lexer rules for command output redirection should be ok now

[eliangcs]

@fogine Cool! Sorry I didn't reply you earlier. I'm looking forward to using this new feature!

[fogine]

@eliangcs , I'm trying to run tests for all python versions via the tox, I've followed the steps you mention in the contribution guide. When I run the tox command in project's directory I get the following error for all python versions except the py34 and py35:

ImportError while importing test module 'path/to/http-prompt/tests/test_cli.py'.
Original error message:
'No module named enum'
Make sure your test modules/packages have valid Python names.

In the contribution guide you mention:

Again, make sure you're not in a virtualenv, run tox

Do I understand correctly that the tox must be installed and run via the system wide python & pip installation?

My ~/.pyenv/versions/ looks like this:

2.6.9/
2.7.11/
3.3.6/
3.4.4/
3.5.1/
http-prompt/
pypy-5.0.0/
pypy3-2.4.0/

and ~/.pyenv/versions/http-prompt/lib/ contains only the python3.5/ directory`

I've installed the tox via pip install tox so the tox binary is now located at ~/.local/bin/tox

Do you have an idea what am I doing wrong?
Thanks!

[eliangcs]

@fogine tox should be installed on one of your pyenv's Python versions. Try doing this:

$ cd /path/to/http-prompt
$ pyenv deactivate
$ pyenv local 3.5.1 3.4.4 3.3.6 2.7.11 2.6.9 pypy-5.0.0 pypy3-2.4.0
$ pip install tox
$ tox

If you run which tox, the output should be ~/.pyenv/shims/tox.

[fogine]

I've uninstalled system wide tox installation and have done:

path/to/http-promptt> which python
~/.pyenv/shims/python

path/to/http-prompt> python --version
Python 3.5.1  # the version is the version from the http-prompt virtualenv

path/to/http-prompt> which pip
~/.pyenv/shims/pip  

path/to/http-prompt> pip install tox
path/to/http-prompt> tox

but when I run the last command (tox) I get the exac same error for the all versions except py34 and py35...