cannot import unpythonic.test.fixtures

[nivpgir]

I'm trying to use the test framework. and as the title says I'm unable to import unpythonic.test.fixtures, or unpythonic.test in general.
It seems the test directory is not installed at all on my system when I look in <venv>/lib/site-packages/unpythonic.

I initially installed from pypi, and got the error, then tried to install directly from github, and still got the error.

I only got it working by cloning the repo, and installing it with editable = true in the pipfile (equivalent of -e flag for pip), and still needed to install mcpyrate separately to actually import it without crashing (otherwise I got a No module named 'mcpyrate' error).

Oh and of course I tried both v0.15.0 and v0.14.3 (just in case, although both their releases contains the test.fixtures module), and got the same results, giving same results.

Is this supposed to work this way? I can understand why the test dir would not be packaged in most cases, but here it seems that the tests actually include files which should be packaged, but are not.

a few factors that might be relevant:

• I'm using pipenv to manage project dependencies
• I'm using windows

[Technologicat]

Hi,

Thanks for reporting!

In theory, unpythonic should work on any OS, apart from the live REPL in the subpackage unpythonic.net, where some of the network code is *nix-specific (PTY management stuff, and perhaps the use of select). I haven't used pipenv myself, but a quick look suggests that the parts relevant here are based on virtualenv and pip, so it should be fine.

Also, glad to hear you're trying out unpythonic.test.fixtures - if you have feedback (bug reports, ideas, general comments, anything), feel free to post it as a new issue.

As for the report:

1. The test framework unpythonic.test.fixtures not getting installed is a bug.

   Looking at setup.py, it seems I've forgotten to tell it to package unpythonic.test. Also, while at it, I've forgotten to package unpythonic.net, too.

   I'll fix this in the next release.

   (The test framework (to be installed) lives in test, while the unit tests (not to be installed) live in tests. These were separated in 0.15.0 exactly so that we could install just the framework.)

2. The lack of a hard dependency on mcpyrate is intentional, at least for now.

   The root of the issue is that unpythonic consists of both pure-Python and macro-enabled layers. The macro expander is only needed when using macro-enabled features (unpythonic.test.fixtures, unpythonic.syntax, and unpythonic.dialects).

   This is something I've thought about a lot, and I'm still undecided on if it's better to keep it this way, or to make the dependency mandatory. Both solutions are Pareto-optimal:

   • Optional dependency (current solution as of 0.15.0): Refuse the temptation to guess: only install what is explicitly asked for. Isolation: allow to be absolutely certain that any bugs in the macro expander cannot affect a pure-Python install. Avoid politics: a part of the Python community frowns upon macros, so avoid introducing them when not needed.

   • Mandatory dependency: Usability: make the installation process as seamless as possible. Least surprise: a package is expected to automatically install all of its features.

   So, it's staying that way for now, but it may change in the future. Maybe needs a larger note at the start of README.md?

[Technologicat]

Fixed in master. 76af517 should fix the test framework not getting installed.

[nivpgir]

Fixed in master. 76af517 should fix the test framework not getting installed

Thanks! that's great I'll try it out right away

This is something I've thought about a lot, and I'm still undecided on if it's better to keep it this way, or to make the dependency mandatory. Both solutions are Pareto-optimal

I can relate to this dilemma, for my two cents:
while I was surprised by mcpyrate not being installed, it was a very minor issue for me, and not a problem at all for me to install, and it was pretty easy to understand the problem and fix it (and I believe it would have been the same even if I hadn't read the tests documentation), and I do appreciate when I am given the option to keep my dependencies as minimal as possible, I do intend to use macros, but if I hadn't I would be annoyed by having to install a dependency that I don't need, so the current state seems preferable for me.

Also, glad to hear you're trying out unpythonic.test.fixtures - if you have feedback (bug reports, ideas, general comments, anything), feel free to post it as a new issue.

Will do once I get some more intense usage from it. I only got it working so far, and only had time to write a couple of tests so far.

[nivpgir]

I changed my Pipfile to install unpythonic from git, and the import works (yay!). So It seems like the unpythonic.test import problem was solved. I had some problems when installing macropy mcpyrate this time, but they were solved by removing all old installations and caches and reinstalling, so this is fixed for me, thanks!

[Technologicat]

Ok, thanks for testing!

Since you mentioned macropy, note that macropy and mcpyrate are not compatible with each other. They will likely not work in the same Python process, because one of the importers for the same file type (.py) will win, and the other one will be ignored.

Maybe I should point out here why unpythonic has switched to use mcpyrate in 0.15.0:

I ended up developing mcpyrate, because I needed some features macropy didn't have. Particularly, I wanted accurate test coverage reporting for macro-enabled code.

macropy suffers a bit from being a first-gen product (albeit a pioneering, very cool one!), so I found it difficult to understand the code. Hence modifying it was not an option for me.

Out from a discussion on the Coverage.py issue tracker, I happened upon the second-gen, clean, pythonic macro expander mcpy, but found it to be more of a (fully working) perfect textbook explanation of how to build a macro expander than a production-ready alternative for macropy.

But once I saw that textbook explanation... I wanted one package that would have accurate test coverage reporting, the functionality of macropy, and any missing features I wished macropy had.

Hence mcpyrate - developing which essentially let me have my cake and eat it too - and porting unpythonic over to it in 0.15.0.

mcpyrate is based on mcpy, but with ≈10× the amount of code, it may have become a bit more difficult to see the forest for the trees. :)

EDIT: added discussion link.

[nivpgir]

Okay that's a cool explanation, but for the record, I totally meant mcpyrate but confused the names 😅 (I'm using 0.15.0).

(I'll edit the comment 😅 )

[Technologicat]

No problem, I thought that might be it, but decided to warn about the incompatibility just in case. :)

(Should benefit future readers, too, if anyone ends up here via Google.)

As for mcpyrate and .pyc caches... macropython -c . to clear caches under the current directory (recursively) may come in useful.

Also, mcpyrate doesn't (yet) support deterministic .pycs (only the default mtime invalidation mode is supported), which might be something to be aware of when you package your own projects that use macros.

Since the test framework is getting correctly installed for both of us now, I'll close this issue. Feel free to open another one for any feedback, discussion, bug reports, or the like.

[Technologicat]

unpythonic 0.15.1 released and available on PyPI. Includes the fix for test framework installation. Enjoy!