From: Jeff A. <ja...@fa...> - 2020-02-03 09:04:51
|
On 03/02/2020 08:45, Adam Burke wrote: > In other codebases I have seen this done reactively as a “poor man’s > dependency conflict resolution”. ie introduce renaming only where > there are conflicts in transitive dependencies, allowing the use of > two different versions of classes with the same full name. > > I don’t know the specific history in Jython, though. Here from the beginning: https://hg.python.org/jython/rev/107fe4a4c96b#l28.7, hence pinging Jim. Unfortunately, it didn't occur to me it might be the wrong thing to leave it so until after I cut a beta 3 (unpublished so far). Now wondering if a beta 4 might be necessary as it seems the sort of change that would need it, in case unshading produces the sort of conflict you're talking about. :( Jeff > > Cheers > Adam > >> 在 2020年2月3日,下午6:36,Jeff Allen <ja...@fa...> 写道: >> >> >> >> When we install Jython we have bundled the contents of the JARs we >> depend on into ~/jython.jar . Some we name-translate: >> >> org/python/apache/commons/compress >> org/python/bouncycastle >> >> And some we just copy: >> >> com/ziclix/python/sql >> jnr/ffi >> >> What drives one choice or the other? >> >> Testing after installation, I get a test failure from test_ssl >> (Unable to create OpenSSL PBDKF: PBKDF-OpenSSL SecretKeyFactory not >> available), where I suspect the shading is the cause. Quite likely, >> something is loaded by its unshaded class name, since if I place >> unshaded BC JARs on the path the test passes. >> >> We seem to have gone to some lengths in _sslcerts.py, for example, to >> use the shaded classes, but must we shade it? >> >> Jeff >> >> -- >> Jeff Allen >> _______________________________________________ >> Jython-dev mailing list >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev |