Fix wheel generation

[Viginox]

Wheel Generation for Packages with src folder

Fixes issue #391

Problem

Packages containing a src folder above the package folder won't have a working wheel package when building the packages with dephell build

Solution

Appending the found package dir to the project package path enables the converter to generate a working wheel package for packages with a src folder as well as for packages without one (when there is no src folder, this parameter contains the value '.' )

Misc

Also fixed a typo in the project_build file.

[orsinium]

Great! That's a good start. As I can see, package_dir keys can have no "" key. For example, if src/__init__.py exists. So, we'll get KeyError in that case.

[Viginox]

Oh, I totally missed that one 😮

Updated the retrieval of the key from the dict with using the get(...) method and a default value.

[orsinium]

Sorry, it still doesn't work. .get return an empty string if no match found, and it fails:

from pathlib import Path
Path().absolute().relative_to('')
# ValueError: '/home/gram' does not start with ''

Please, include a few test cases. This should help to see what is possible:
https://github.com/dephell/dephell_discover/blob/master/tests/test_root.py#L42

Thank you for taking care of this. I've done with most of my other projects, so now I'll try to give you feedback faster :)

[Viginox]

I think I figured out the reason for that. I set the default value to "" (empty) instead of the current directory ".".
I rewrote the code to check if the dictionary is empty and if not, it takes the first value of the dictionary. This is usually only one entry.

I must confess, I don't know where I can write those testcases. You wrote all testcases very generic in the test_all.py file. All other converters only implement testcases for loading.
I try to stick to your scheme of implementing those tests, but at the moment, it is a little bit overwhelming.
Could you give me a hint or an example how to implement the dump test for the wheel package?

[Viginox]

Taken from your next comment:

"Using the current dir as default is not correct."

If the local folder is not the best default value for that, what would you consider a good alternative?
I think, if the project folder was set for another path, that path should be in that structure nevertheless.

Falling back to the value project.package.path might be a safe choice for that situation.

[Viginox]

Figured out another approach, which corresponds with how setuptools is generating the wheel package.
The exact approach is described in the commit messages and in the source code itself.

[orsinium]

I think you can make a project structure in temp_dir fixture, dump it, and then open it with zipfile and check the dumped structure. Like in the tests I shared above.

Using the current dir as default is not correct. The project can be located somewhere else. I can't say for sure right now, I'm away from the laptop. However, you can make just tests, and I'll help you with the solution. I understand if you lost here, we definitely need more internal documentation. Right now I'm working on type annotations for everything, it should help a bit :)

Off topic: Hmm, why fasthub can't comment on threads?

[Viginox]

@orsinium Thanks for the starting point. I'll try to implement some testcases for that.
I think I still need to dig into how to execute the wheel generation properly with as little as possible overhead.

[EDIT] Off topic: Commenting on a thread using fasthub worked for me. Expanded the thread and then there is a separate "Add Commend" filed on the bottom of that thread.

[Viginox]

While working on this new method to generate the wheel package, I might have encountered a different issue in dephell_discovery, but still some investigation is necessary.
Will look into that, the next days.