There is a circular dependency between this and `lisp-unit2`.

[kat-co]

0c80429 migrated the tests to lisp-unit2, but every version of lisp-unit2 relies on symbol-munger. Therefore, it is impossible to test this project unless:

• You already have a version of lisp-unit2 available
• You first build a version of symbol-munger that does not rely on lisp-unit2 so that you can build lisp-unit2, so that you can build the latest version of this, so that you can build the latest version of lisp-unit2.

This poses an issue particularly for folks trying to package this (hi!).

[bobbysmith007]

I see what you are saying, but I am not sure how to easily resolve that.

FWIW, there is not an actual circular dependency as :lisp-unit2 relies on :symbol-munger, and :symbol-munger-test relies on both :symbol-munger and :lisp-unit2. So while symbol-munger breaking might cause your tests to be inoperable and that would be difficult, there shouldn't be any actual build-time issues.

Additionally I am moving away from having much to do with common lisp, and as such, I am unlikely to have time to maintain this project regularly.

[kat-co]

I think it depends on which semantic level this is viewed against. From a Common-Lisp system perspective, yes, there's no issue. OS packages encompass the result of building -- but only after tests succeed -- so the semantic level is the build output and a successful execution of the test suite. I can appreciate the difference, but not taking the OS semantic level into account makes it difficult to package.

I'm not familiar with the project, so it would be difficult for me to make any suggestions. The only ideas I have are:

• Switch back to lisp-unit (does lisp-unit2 solve any issues this project utilizes?)
• Use a different unit testing framework
• Vendor lisp-unit2

Thank you for responding. I understand that you're moving away from c-l. Hopefully this can still be addressed at some point.

[bobbysmith007]

Well... I am the author of both lisp-unit2 and symbol-munger. Both were written to resolve real issues I was having with other less robust versions of each of these functionalities. I could write / copy an un-isolated version of symbol-munger code into lisp-unit2, but that seems neither required nor desirable. Both are utility libraries providing a narrow window of functionality and it doesnt make sense to me that they shouldnt reference each other.

From a build perspective, you should be able to fully package this project. The tests succeed and the test suite runs, all build dependencies are fully statically resolvable. In some future where symbol-munger or lisp-unit2 changes, the test suite may become hard to build / broken until debugged, but for now - as both things work - this shouldn't present any issues packaging as each can be built and then tested.

Lisp-unit2 also uses a lisp-unit2 test suite, which would also fail if lisp-unit2 doesn't work. I guess I am failing to see the distinction you are trying to make. I do understand that these systems are interrelated and that one breaking could break both, but that is almost the point of having them test each others functionality.

In conclusion: If everything works and builds and can be verified - where is the issue? If things are not building and testing, then they probably aren't ready for OS-level packaging anyway. Additionally quicklisp provides a package system for lisp independent of OS-level packages, and generally speaking I have not found OS packages much use in common lisp vs quicklisp distributions, though YMMV.

Thanks for starting this discussion as I dont think I have personally thought about it much in the past and so could definitely be missing things.

[kat-co]

I apologize for not responding in so long. Unfortunately the time I have to dedicate to this kind of thing is so small, that things slip between the cracks :(

From a build perspective, you should be able to fully package this project.

This is only partially true. I was able to package it, but not without creating a bootstrapping package as laid out in the second bullet-point in my original message. This adds a lot of complexity.

I packaged this for Guix. One of Guix's core values is software reproducibility. Rather than try and reproduce information about what that is and why it's important, here's a good reference. I hope this helps.

This will be the last comment I leave, so please feel free to close the issue if you don't find it helpful being open. Thanks for your time!

[catap]

Another approach is split symbol-munger.asd into two parts: symbol-munger.ads and symbol-munger-tests.asd. The last one depends on symbol-munger.asd and lisp-unit2.asd and everything can be managed on package level.