Support for Legends

[ppseverin]

Regarding this question I posted 2 days ago, I started to inspect the code and made some changes. Now I'm able to do this:

mpf.make_addplot(bars[["sma_10","sma_200"]],labels=["sma_10","sma_200"])

Is this useful to the community? What other testing is needed and how do I submit the changes to see if they are approved?
Its the first time I change the code of a library I downloaded.

Hope you will find it useful. The results are in the image below.

[DanielGoldfarb]

Hi. Thank you very much for your interest in contributing code to mplfinance.

The standard way to contribute code on GitHub is to use the "fork-clone workflow." I will assume you are somewhat familiar with git itself, but if not, that's fine; just let me know and I will walk you though the steps in more detail.

The fork-clone workflow (click here) is essentially this:

1. You fork the repository (mplfinance). This makes a copy of the repository in your github account
2. You clone your fork of the repository, creating a local copy on your local machine.
3. Make your code changes locally, and test them.
4. git Push your changes back to your fork
5. Submit a pull request to the main repository (https://github.com/matplotlib/mplfinance). This is a request to "pull" the code from your fork, into the main repository.
6. The code gets reviewed and, if acceptable, gets merged from your fork, into the main repository.

Since this is your first time, I suggest the following:

• read the "fork-clone workflow" link posted above.
• before submitting your pull request (but after you have pushed to your fork) contact me and I will review the code in your fork. This can save time if there are any issues with merging the code.

You can contact me either by posting here on this issue, or by emailing me at dgoldfarb.github@gmail.com

Please let me know if you have any questions.

All the best. --Daniel

P.S. there is also a little more detail about forking here.

[ppseverin]

Thank you for the datailed steps, Daniel. I will try to follow this instructions and if any question comes up, I'll write you an email. One thing, do I need to run git init before forking or cloning the repository or its not necessary in this case? Sorry the noob question. I have started to use git since like 1-2 days and still learning :)

[DanielGoldfarb]

• git init is not necessary since the repository already exists. (Only use git init when creating a brand new repository).

• fork is a button click on github.com

• git clone <url> is a command run on your local machine to "clone the fork" from github to your local machine.

hth. --Daniel

[ppseverin]

Okay. I think I did it right? Had a little bit of trouble at the beginning, but seems to be okay now. How can I know if I pushed all files right? Will I get any feedback or something?

(push...pull...sometimes a litttle confused with that, but getting used to :) )

Let me know Daniel if its all okay!

[DanielGoldfarb]

You can tell if the push worked by going to your fork and clicking the compare button. Then scroll down and look over the diff and make sure it makes sense in terms of the changes that you expect that you pushed.

I can see your pull request here. It appears you did the push, and PR (pull request) correctly. One thing to be aware of (and this is good) ... the way GitHub PR's work is that as long as the PR is open, any additional pushes (on same branch) to your fork will automatically propagate into the PR. That's good, because if I ask for any changes all you have to do is make those changes and push again ... and those changes will propagate into the existing pull request.

That said, it's late here and I have a very busy day tomorrow, so I may not have a chance to look over the code until Monday. Meanwhile I can tell you this much: The reason the Travis checks are failing on the PR is because one of the checks we put in place checks to make sure that each PR increases the version. You can do this by modifying one line in file _version.py from

version_info = (0, 12, 7, 'alpha', 1)

to

version_info = (0, 12, 7, 'alpha', 2)

If you change the version and git push to your fork again, then hopefully the automated regression tests will all succeed.

[DanielGoldfarb]

Please see code review comments that I have posted on the PR.

[ppseverin]

Hi Daniel, I just saw the comments you left on github. I did not noticed that the labels needed to be treated as a tuple or list. I agree with you that the labels should be converted to a list if the label is only 1 string. I can add that change and also add the change of using ' ' and not " " (sorry about that). Regarding the part that you said that I removed something from the code, when submitting the code I changed I noticed a lot of red lines that supposedly I changed. However, I found it strange because I did not delete any line and I guessed that those were deleted lines from before. The process I did was: 1. Fork the repository 2. Clone the repository to my local machine 3. Replaced the cloned files with the files that I had changed, that where in already in my local machine (those files were form the installation files of mplfinance) 4. Commit 5. Push back to my repository 6. Made a pull request Are these the steps that I should have followed? How should we proceed? Best regards, PS El lun., 19 oct. 2020 a las 14:41, Daniel Goldfarb (< notifications@github.com>) escribió:

…

Please see code review comments that I have posted on the PR. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#276 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOWW5JLDYVZ2BBGNZ3VJGQLSLR26HANCNFSM4SURPZKQ> .

[DanielGoldfarb]

Pedro,
Thank you for the detailed steps. This is an interesting problem and I learned something new today, which I will share shortly.

The steps are correct except for step 3

3. Replaced the cloned files with the files that I had changed, that where in already in my local machine (those files were form the installation files of mplfinance)

It is a good thing that you were very clear about where the files came from, or I might still be very confused as to how this could have happened. It happens often, in many projects, that the version on pypi.org can differ from the version in the github repository.

This is because one or more Pull Requests may be accepted into the repository before the maintainers decide to release a new version to pypi.org, thus the repository may be any number of commits ahead of the pypi.org installation version.

In the case of mplfinance, presently pypi.org is on version 0.12.7a0, while the repository is at 0.12.7a1 and has the additional enahcnements to the title kwarg. Since you used the files from your installation, those files did not have those changes. But no worries. This is relatively easy to fix. There are two approaches, and you can choose the one you are more comfortable with, but I recommend the second approach because it more fully utilizes the power of git, and it avoids the need to manually re-edit to add your changes again.

1. The first approach is basically to go back in time and re-apply your changes manually instead of copying from your local files. You can go "back in time" by checking out the version of plotting.py from before you applied your changes:
   git checkout HEAD~1 src/mplfinance/plotting.py. You then manualy edit src/mplfinance/plotting.py and manually apply your changes to that file for the labels enhancement. Then test, commit, and push to your fork, and this will propagate to the pull request.

2. This approach I just learned today after some googling. Essentially two changes were independently made to one base version of plotting.py: (a) your changes for labels, and (b) Teddy Rowan's changes for the title kwarg. Those two independent changes need to be merged together, and the simplest way to do that is to do a "three way merge."
   
   Effectively it is just a merge of the two enhancements (a) and (b), but in order to correctly merge them, the merge tool needs (as a third file) the "base file" from which each of the two enhancements was derived. You already have your version of plotting.py.
   
   We can generate the previous version (that you accidentally skipped), and the base version, using the git cat-file command. In order to do this we need to know which commits contain the file version that we want. The previous version (that you skipped) is easy, because we know you made only one commit, so we can use HEAD~1. But to get the base version, we need to know the commit SHA-1. We can get this from git log. But first we need to know how far back that was:
   
   Pypi.org shows that "installed" version of mplfinance was last updated on Aug 9 (see upper right corner of pypi page).
   
   git log --pretty='%h %cd %an' -10  displays the following:

0d8df09 Sun Oct 18 02:13:06 2020 +0000 Pedro Severin
7b1b722 Mon Sep 14 21:26:38 2020 -0400 Daniel Goldfarb
3af71a8 Sun Aug 16 20:58:45 2020 -0400 Daniel Goldfarb
f5c1338 Sun Aug 16 20:16:45 2020 -0400 TR
1685252 Wed Aug 12 23:02:51 2020 -0400 TR
278e4b4 Sun Aug 9 14:21:48 2020 -0400 Daniel Goldfarb
a1ddfdd Sun Aug 9 14:18:25 2020 -0400 Daniel Goldfarb
f3bbcb7 Fri Aug 7 12:22:51 2020 -0400 Daniel Goldfarb
9b1516f Fri Aug 7 11:52:55 2020 -0400 Daniel Goldfarb
02ba8ac Fri Aug 7 11:52:55 2020 -0400 Daniel Goldfarb

From the above we can see that the version you started with, the "base" version, from Aug 9 is 278e4b4
And the previous version, that you accidentally skipped, that is represented by HEAD~1, is 7b1b722

Now we can generate the skipped version file, and the base version file, and do the three way merge as follows:

git cat-file -p 278e4b4:src/mplfinance/plotting.py > src/mplfinance/plotting.base.py
git cat-file -p 7b1b722:src/mplfinance/plotting.py > src/mplfinance/plotting.skipped.py
git merge-file src/mplfinance/plotting.py src/mplfinance/plotting.base.py src/mplfinance/plotting.skipped.py

src/mplfinance/plotting.py now contains the merged contents.
You can verify this with git status and git diff.

Now commit the merged contents:

git commit -am 're-apply skipped commit for title dict'

Now test. If everything looks good, then git push to your fork and it will propagate into the Pull Request.

I really enjoyed learning this today. I had personally never used git merge-file nor git cat-file so it was fun to learn and try.

I hope that helps. Feel free to do whichever approach with which you are more comfortable. And I very much appreciate your willingness to contribute to mplfinance. I hope you are enjoying and learning from the process.

All the best. --Daniel

[DanielGoldfarb]

By the way, just in case you are not aware: There is a very easy way to install the version of any python package that you are working on. Simply go to the top level source code directory, the one that contains the file setup.py and type the following:

pip install -e .

Note the dot at the end. That is important. This creates an "editable" install (-e) which means that any changes you make to the repository there will be immediately reflected in the installed package. No need to reinstall every time you tweak some code and want to test. I find this very convenient when I am working on a change.

[ppseverin]

Daniel, Well I see now why the differences. I'm sorry to cause you such trouble, I didn't knew that there could be different versions on github and pypi. Actually, I thought that pypi always had the most recent version of the code. That had some synchronism with github and automatically updates repositories as they were updated in github. I'll pay more attention to that in the future. It's funny, because I know how to code reinforcement learning methods and some other fancy machine learning stuff (especially for trading), but I don't really know how to use git, which seems to be absolutely basic to many people. I guess that's because I have always worked alone and haven't had the need of using git, until now. So yeah, I enjoy the process of learning new things. Especially if they are useful like git. Regarding the solution to merge the files, I think that option 1 is probably the fastest, but I would definitely like to try and learn how to do option 2. So, if we are not in a rush I would like to give it a try and learn how to use git properly. If not, then I can just edit manually the code and use another git push. Let me know what you think. Best regards, PS El mar., 20 oct. 2020 a las 17:33, Daniel Goldfarb (< notifications@github.com>) escribió:

…

By the way, just in case you are not aware: There is a very easy way to install the version of any python package that you are working on. Simply go to the top level source code directory, the one that contains the file setup.py and type the following: pip install -e . Note the *dot* at the end. That is important. This creates an "editable" install (-e) which means that any changes you make to the repository there will be immediately reflected in the installed package. No need to reinstall every time you tweak some code. I find this very convenient when I am working on a change. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#276 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOWW5JNKUAS3B2DYT7DXFX3SLXX25ANCNFSM4SURPZKQ> .

[DanielGoldfarb]

Pedro,

There is no rush. Take your time. Git, unfortunately, has a steep learning curve. I was using svn and resisted learning git for a long time. When I finally decided to learn git, I learned just a few basic commands and used only those commands for a long time until I felt more comfortable. It is becoming the "defacto" standard for collaboration, and for good reason. It takes a while to learn, but it is very powerful. I find when I'm wondering how to do something with git a little googling usually finds the answer.

Regarding trying new things with git and the repository, as long as you do not push to your fork, if you make a mistake in your local repository you can always delete it (or move it aside) and clone again from your fork. I actually did that several times today (re-cloning your fork) as I was experimenting with differrent approaches to be able to merge the correct versions of the plotting.py file.

All the best. --Daniel

[ppseverin]

Hi Daniel, I hope that this email finds you well. I did followed the steps of: git cat-file -p 278e4b4:src/mplfinance/plotting.py > src/mplfinance/ plotting.base.py git cat-file -p 7b1b722:src/mplfinance/plotting.py > src/mplfinance/plotting.skipped.py git merge-file src/mplfinance/plotting.py src/mplfinance/plotting.base.py src/mplfinance/plotting.skipped.py But I noticed that plotting.py now has like ~1800 lines. Maybe it's another noob question of mine, but did I have to previously delete the plotting.py file before merging? Because, if I'm not mistaken, a merge operation should add the differences of plotting.base.py and plotting.skipped.py to plotting.py, right? And after all this, I should delete plotting.skipped.py and plotting.base.py to only commit plotting.py? I have a feeling that I did something wrong here :( Best regards, PS El mar., 20 oct. 2020 a las 18:14, Daniel Goldfarb (< notifications@github.com>) escribió:

…

Pedro, There is no rush. Take your time. Git, unfortunately, has a steep learning curve. I was using svn and resisted learning git for a long time. When I finally decided to learn git, I learned just a few basic commands and used only those commands for a long time until I felt more comfortable. It is becoming the "defacto" standard for collaboration, and for good reason. It takes a while to learn, but it is very powerful. I find when I'm wondering how to do something with git a little googling usually finds the answer. Regarding trying new things with git and the repository, as long as you do *not* push to your fork, if you make a mistake in your local repository you can always delete it (or move it aside) and *clone again* from your fork. I actually did that several times today (re-cloning your fork) as I was experimenting with differrent approaches to be able to merge the correct versions of the plotting.py file. All the best. --Daniel — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#276 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOWW5JOE34LESXN2O2HVBQLSLX4UXANCNFSM4SURPZKQ> .

[DanielGoldfarb]

Sounds like it might be OK. You're understanding seems to be correct. I'll take a closer look soon and let you know.

[DanielGoldfarb]

... a merge operation should add the differences of plotting.base.py and plotting.skipped.py to plotting.py, right?

This is correct!

did I have to previously delete the plotting.py file before merging?

Absolutlely not! At the beging of the above operations plotting.py should be the version that is currently in your fork, which is also identical to the version currently in the Pull Request. It contains 963 lines.

And after all this, I should delete plotting.skipped.py and plotting.base.py to only commit plotting.py?

You can delete .skipped and .base if you want to. Certainly they should not be added to the repository. Yes, commit only plotting.py

---

I just reproduced the process as follows:

dino@DINO:~/code/pr277$ git clone git@github.com:ppseverin/mplfinance.git
Cloning into 'mplfinance'...
remote: Enumerating objects: 56, done.
remote: Counting objects: 100% (56/56), done.
remote: Compressing objects: 100% (33/33), done.
remote: Total 2525 (delta 27), reused 35 (delta 19), pack-reused 2469
Receiving objects: 100% (2525/2525), 45.94 MiB | 8.95 MiB/s, done.
Resolving deltas: 100% (1423/1423), done.

dino@DINO:~/code/pr277$ cd mplfinance
/home/dino/code/pr277/mplfinance

dino@DINO:~/code/pr277/mplfinance$ wc -l src/mplfinance/plotting.*
963 src/mplfinance/plotting.py

dino@DINO:~/code/pr277/mplfinance$ git cat-file -p 278e4b4:src/mplfinance/plotting.py > src/mplfinance/plotting.base.py
dino@DINO:~/code/pr277/mplfinance$ git cat-file -p 7b1b722:src/mplfinance/plotting.py > src/mplfinance/plotting.skipped.py
dino@DINO:~/code/pr277/mplfinance$ wc -l src/mplfinance/plotting.*
   953 src/mplfinance/plotting.base.py
   963 src/mplfinance/plotting.py
   965 src/mplfinance/plotting.skipped.py
  2881 total

dino@DINO:~/code/pr277/mplfinance$ git merge-file src/mplfinance/plotting.py src/mplfinance/plotting.base.py src/mplfinance/plotting.skipped.py
dino@DINO:~/code/pr277/mplfinance$ wc -l src/mplfinance/plotting.*
   953 src/mplfinance/plotting.base.py
   975 src/mplfinance/plotting.py
   965 src/mplfinance/plotting.skipped.py
  2893 total

You can see from the above that plotting.py went from 963 lines to 975 lines (by inserting the differences between .base and .skipped, as you mentioned above). The only thing I can think of that may have gone wrong is possibly you had either some other edits to the local src/mplfinance/plotting.py and/or some other commits. Did you try the git log --pretty='%h %cd %an' -10 and did its output look like what I posted above?

At any rate, I reccommend that you go to a clean location (directory) on you system, and start with a fresh clone of your fork (as I did above). It should work then. Let me know. Thanks.