PEX is not packaging its subpackages and its Dependencies

[itsmesrds]

i have structured folder that contains

->tree
--->package1
---------->package2
---------->init.py
---------->main.py
--->setup.py
--->requirements.txt
--->package1.wheel

i want to build pex file for this structure.when i use command in tree folder "pex --python=python3 -rrequirements.txt package1 -e package.main -o samplepkg.pex"

When i try run the samplepkg.pex ...Error:package2 not found .....when i run the pex file deactivating the environment ...dependencies module not found

Is this Tox is for packaging dependencies module and subpackages rite..?

[jsirois]

It would be helpful if you could:

1. give the full output of the error
2. give a zip listing of the generated samplepkg.pex file
3. make sure the directory tree you describe is accurate

Drilling down on point 3 - right now the command line you gave: pex --python=python3 -rrequirements.txt package1 -e package.main -o samplepkg.pex does not match the directory structure you listed, which has package1/main.py which does not match your command line entrypoint -e package.main. This may have just been a typo when filling out the issue description, but to debug things from here it helps to know for sure.

[jsirois]

One more bit of debug advice: pex should package exactly what setup.py packages. PEX basically just runs python setup.py sdist on the setup.py you point to. So first ensure python setup.py sdist creates exactly the distribution you expect. If it does, then you can more confidently be sure there is a pex bug.

[itsmesrds]

Thanks for debugging advice. it is rectified.
But pex is using cache to create pex file.even though i have used "pip3 wheel -w . ." and if i delete the wheel file still we are able to generate the pex..?

If i change any command in setup.py file and iam building a new wheel ....still it is using OLDER cache ...

[jsirois]

If i change any command in setup.py file and iam building a new wheel ....still it is using OLDER cache ...

That's a bug, but its pretty far afield of the initial issue report here. I'm going to close this issue as answered and let #620 stand in for this narrower issue.