Move phpCAS to github

Migrated from PHPCAS-129
Description
I would like to move phpCAS along with the other cas server and clients to move to github. This allows for a more open development model much more flexibility. It would be great if everyone could simply add an opinions, votes or objections.
A jasig group already exists https://github.com/Jasig
I would like to shedule this shortly before the 1.3.0 release (pushed it back to end of october since we are still doing a lot of work) when all the branches are merged and no more major work is done. This would allow for a really easy transition.
Adam Franco added a comment - 14/Sep/11 9:49 PM
Yay!!!!!
I've been using git and GitHub for all of my PHPCAS work for years and have been automatically tracking the SVN repository there as well. See: https://github.com/adamfranco/phpcas/ I wrote a script to track the SVN repository and make nice git tags for all of the SVN tags (which come through git-svn as branches) and this script currently updates my github repository with the latest changes from SVN every 30 minutes.
I use Git hub for a lot of other projects and would love to take on the migration duties.
To do the migration, I (or anyone) can copy my Github repository to the Jasig space and I can update my git-svn scripts to keep the repository in the Jasig space in sync with SVN at first. Once we decide to start pushing directly to the Github repository the git-svn scripts will gracefully fail as its pushes for each branch become non-fast-forward. From there on out we just ignore/remove the SVN repository and keep working with Github.
While the technical aspects of the move are very easy (If granted access to the Jasig space I can move the repository and update the scripts in about 15 minutes), the bigger question is what workflow model we should use once freed from the single-workflow constraints of SVN.
Option 1: Small team with central repository, forks for new/less frequent contributors.
This is the model my team at Middlebury College uses for our development and the Kurogo project that I just started contributing to uses.
In this model a small number of trusted team members all have push access to the main repository, allowing any of them to integrate feature branches or fixes into the master. New, infrequent, or other contributors simply fork the repository, do work, push back to their repository, and then submit a pull request. One of the team members then reviews the pull request and optionally merges it into the central repository onto the master branch or a branch for further work as appropriate.
Option 2: Single maintainer with central repository, forks for all contributors.
This is the model used by the Linux kernel.
In this model a single maintainer is in charge of reviewing pull requests from all contributors and merging them into the master branch. There is more overhead for the maintainer, but also more control.
Option 3: Many contributors with central repository
This is the old SVN model were anybody wanting to contribute needs commit access. This allows the entire large team to merge fixes into the official master. It lowers the overhead for the maintainer, but has much less control over what gets in.
I guess my vote would be for option 1 or 2, just to keep a bit more review and oversight as to what is considered ready for the next release. This leverages the power of github's pull-request system for infrequent contributors, making it easy to contribute without having to grant trusted access before any work is done.
I'd be happy to work under either model 1 or 2 as you see fit, Joachim.
Adam Franco added a comment - 14/Sep/11 9:55 PM - edited
One other note, if going with the Jasig space I'd recommend renaming the 'phpCAS-Client' repository to 'phpcas' since the repository name will be the default directory name every time someone clones the repository and phpCAS has always been been known as 'phpCAS', 'phpcas', or 'phpCAS', but not 'phpCAS-Client'.
This will be much harder to change later once people start watching and forking the repository, so the name should be right from the get-go.
Joachim Fritschi added a comment - 15/Sep/11 12:09 AM - edited
I noticed the weird name already. Scott just named it like that but we should definately rename like you suggest. I would suggest 'phpcas'.
My option would really be Option 1. Single point of contact/work is not ideal in a small team like this. I guess you an me should have push access. I don't see any issues there. As long as we stick to our current mode of operation (JIRA issues, discussion etc.) i really have no objections.
Regarding the move: It seems you are much better prepared to do this merge. I'm happy to leave the work to you if you are willing There should be some docs on the wiki about the move of the main cas-server that marvin made this weekend. Can you take a look and see if we learn something from his work? There was a longer discussion around development/maintenance trees etc. I'm happy that you take the lead. I'm not that familiar with git. Most of my work was always svn but this is now shifting and i definately see the advantage of git.
I just sent scott a mail to add you on github with the appropriate permissions.
Scott Battaglia added a comment - 15/Sep/11 12:26 AM
Its already been renamed.
Adam Franco added a comment - 15/Sep/11 4:20 PM
I've read through the jasig wiki a bit and the one thing I didn't account for in my early export to Git was mapping the SVN username to git author name/email combos.
In Git, authors are referred to using a name and email, e.g.:
Adam Franco<EMAIL_ADDRESS>By default (and when I exported the repository before), git-svn records authors as svn-username/hash. e.g.:
adamfranco adamfranco@f5dbab47-78f9-eb45-b975-e544023573eb
While I could leave it as-is, it would probably be nice to re-do the export with proper names for contributors – just a little more work for nicer history going forward. Searching through the phpcas-devel list I think I was able to account for everyone. Does this mapping look right?
fritschi = Joachim Fritschi<EMAIL_ADDRESS>adamfranco = Adam Franco<EMAIL_ADDRESS>jmarchal = Julien Marchal<EMAIL_ADDRESS>paubry = Pascal Aubry<EMAIL_ADDRESS>selwood = Matthew Selwood<EMAIL_ADDRESS>mbrooks = Matthew Brooks<EMAIL_ADDRESS>olivierberger = Olivier Berger<EMAIL_ADDRESS>brianxlong = Brian Long<EMAIL_ADDRESS>saltybeagle = Brett Bieber<EMAIL_ADDRESS>Adam Franco added a comment - 15/Sep/11 9:10 PM
Ok, so have rebuilt a git repository from SVN using the author names above and pushed it to:
https://github.com/Jasig/phpCAS
This the github repository is currently being updated every 15 minutes from SVN. I can rebuild it with different author names or other parameters and re-push it if needed. Once we start using it however, we won't want to rebuild it as all of the commit IDs would change and any clones and forks of the repository.
Try cloning it with and visualizing it in gitk by:
git clone git@github.com:Jasig/phpCAS.git   # read/write for Joachim
# or
git://github.com/Jasig/phpCAS.git    # readonly

cd phpCAS
gitk --all&

Let me know anything looks amiss.
Also Joachim, you'll want to go into your Github account settings and add your email address so that Github will associate all of your commits with your account. If you use a different email address on other projects you can add as many as needed and all will be attributed to your account.
Is there a plan for the other CAS projects to continue using JIRA/Confluence for issue tracking and wiki or move to those included in Github?
The Github issue tracker is pretty basic, but it does have support for assigning issues and adding them to milestones. One nice aspect of using it is that commits that mention issues automatically get linked into the issue comments (example) and issues and pull requests are pretty tightly integrated.
On the flip side, apparently there are JIRA plugins for working with git/github.
Joachim Fritschi added a comment - 16/Sep/11 2:04 PM
Please use<EMAIL_ADDRESS>as my email. The other one does not exist any more.
I will have a more detailed look this weekend at the git repo. As far as jira goes the decision on the cas-dev mailing list was to keep jira for the cas-server. I don't know if there is any reason for or agains moving phpcas only. But i think being in one consistent issue tracker for all official clients is nice. Haven't really thought about it but i will have to check the thread again and check for the reasons to stay on jira.
Adam Franco added a comment - 16/Sep/11 2:56 PM
Joachim, I have updated the repository on Github with your correct email address.
Joachim Fritschi added a comment - 17/Sep/11 4:01 AM
Thanks, however from what i can see github assigns new commits to my account but all "old" ones are not really linked to my account.
Adam Franco added a comment - 17/Sep/11 7:51 AM
Can you describe a bit more of what you are seeing versus what you are expecting?
When I look at the commit list or a single commit the author is listed as jfritschi with a link to https://github.com/jfritschi
Joachim Fritschi added a comment - 17/Sep/11 7:58 AM
I have attached a screenshot of what i'm seeing.
Adam Franco added a comment - 17/Sep/11 7:26 PM
Ah, I see. The source code file listing isn't always showing the right thing. My guess is that this is an issue with Github as I've done a fresh clone of the repository and searched through all of the commits and 'Joachim Fritschi<EMAIL_ADDRESS>is the only name used for you. All of the commit views in Github seem to properly link to your account, as do all of the 'blame' views on any of the files that show an unlinked 'Joachim Fritschi'. It seems that only the source view's last-change author indicator is off.
I've tried deleting everything from the repository and re-uploading it, but with the same results. I sent a support email to github, hopefully they'll get back to me with a work-around or a fix for the 'Source' view.
Adam Franco added a comment - 19/Sep/11 6:59 AM - edited
I received a response from Github support:
"The incorrect pages will update as they fall out of the server's cache."
I guess the error was on their end and will show up correctly soon.
Adam Franco added a comment - 04/Oct/11 9:07 AM
The github source view now seems to properly link up Joachim's commits. We are currently in a quiet period for a few weeks and as well Bradley Froehle submitted a pull request against the Github repository: https://github.com/Jasig/phpCAS/pull/1
This seems like as good a time as any to just stop using SVN for the trunk/master and let the Github master continue on ahead. To this end, I have merged Bradley's patch via git, so the Github master branch has now forked from the SVN trunk. I verified that my git-svn script has successfully failed updating trunk->master due to the change being non-fast-forward, while the other issue branches continue to be updated from SVN.
I'll update the wiki documentation to refer to the Github repository and submit a request to make the SVN repository read-only.
Adam Franco added a comment - 04/Oct/11 10:27 AM
I have now updated the Development documentation with detailed instructions on the [current] Github workflow: https://wiki.jasig.org/display/CASC/Developing+phpCAS
Adam Franco added a comment - 04/Oct/11 10:40 AM
I have created PHPCAS-133 for locking down the SVN repository to read-only state.
I think the migration is pretty much complete the only remaining thing I can think to do is to advertise the change on the mailing lists.
Joachim Fritschi added a comment - 26/Oct/11 2:15 PM
Shouldn't we delete the old code and just leave a note like they did for the cas3 code?
https://source.jasig.org/cas3/README.txt
You can announce the new repo if you want.
Joachim Fritschi added a comment - 26/Oct/11 2:18 PM
What about the issues tracking? People are starting to use the github issues and we should soon decide on a policy where we want to track stuff. I'm happy with the features of jira but i also see the advantages of github...
Any preference for you?
Adam Franco added a comment - 26/Oct/11 2:43 PM
I sent the email below yesterday, but it might have gotten lost in the aether. Short answer: my preference would be to move to Github for issue tracking and make full use of the integration and linking.
Deleting the code via SVN is a great idea. I'll do so in a few minutes.
I can write up an announcement and send it to the phpcas-users list. I never got approved to send to the phpcas-devel list, so if that list is still in use would you mind forwarding the message to it?
Hi Joachim,
I hope you had a relaxing vacation!
I'm not sure if you have noticed, but since we put the repository on GitHub, we have had 3 issues submitted already by users, one including a pull-request. It seems that the barriers to entry for using GitHub are lower than Jira, maybe just due to people already having GitHub accounts.
Having two issue trackers is a bit confusing though, so I would like suggest that at some point we either disable the GitHub issue queue or move to it exclusively and disable Jira.
In working with these three issues I have found the integration with the repository to be quite nice – commit ids and issue ids all become HTML links, and it is easy to associate commits with issues by including '#2' or 'gh-2' in the commit text. Based on these experiences and the increased participation I'd prefer to go with the GitHub issue tracker, but would be happy to continue using both for a while longer so that you can get a chance to try out the Github tracker.
What are your thoughts? Are there features of Jira that you would rather not give up?
Best,
Adam
Adam Franco added a comment - 26/Oct/11 2:51 PM
Code is now deleted from the SVN repository: https://source.jasig.org/cas-clients/phpcas/
I'll copy over the remaining issues to the Github tracker and we can then update the wiki and announce the move of both the repository and issues at the same time.

All issues have now been moved into Github.

What shall we do as a naming convention for branches related to Github issues? Maybe one of the following?

Call them phpCAS-xxx where xxx is the renumbered Github issue number.
Call them phpCAS-xxx-Short_Issue_Title where xxx is the renumbered Github issue number.
Call them Short_Issue_Title

I don't believe Github does any association between issues and branches when there is not a pull-request, but rather associates commits with issues based on mentioning the issue number in the commit comment as one of #xxx, gh-xxx, or GH-xxx.

I think phpCAS-xxx would be best. Anything else will get kinda messy ;) This however does interfere a bit with the old branch names...
I just noticed another oddity. The tags are all show as zip files for download. This is not optimal. While they are pretty much equivalent to the distro the do not contain the codedocs, version number and PEAR. I'm not sure what the normal place for binaries would be and how do we want to release new versions in the future?
Right now i have an ssh account on the jasig server to upload new release. (done via the ant build.xml) I'm open to new idea if you have any better ideas. I should however be automated ;)

Ooh so many options... My main concern for this redesign/rethinking are:

PHPCAS_VERSION is an indispensable info when supporting users with bug reports etc.
breaking existing linking to our binary repository and some of the symlinks used for PEAR
reduce the amount of possible duplication both for the users and us.
automated and reproducable release process. Maybe even auto generating changelogs, doc update etc.

I haven't had time to do any real analysis but here are a few first thought i had going through your options:

A has the downside that some people will jump on the tags and not realise that they are not getting the final version with debug info. And having pretty much identical versions in two different places... :(
B as you have already concluded: ugly
C has some charm but somehow does not feel right ;)
D sounds interesting but having 2 projects seems a bit overkill
E sounds ok if we can automate it ?

I just uploaded CAS-1.2.2.tgz to the downloads section, but this doesn't seem to really help. The way Github displays download options for tags it still isn't obvious where to get the 'official' release. Because of this, I'm tempted to go down the route of making the tagged commits functionally equivalent to any packaged releases so that it doesn't matter what way users get the code.
What is the  process you use for building releases? The wiki mentions having ant, Doxygen, and PEAR_PackageFileManager available, but not what commands to run to build the release. I tried just running ant in the root directory, but I wasn't clear what files get uploaded to the PEAR repository and which other ones are copied somewhere else.
Just to test, I created a Rearrange_Build_and_Source branch that moves all of the ant-related files to the utils/ directory and moves CAS.php and CAS/ up a level out of source/. If you check out this branch, just cd to utils/ before running ant. This is only about halfway there since we still need to update the VERSION in the source before tagging and do something about pointing to a remote URL for the docs so that those who get PHPCAS from the source repository have a valid link for the API docs. I'm still unsure about what needs to go where, but we can probably update the build.xml to make the process more automated maybe even automating the Git commands for tagging the release (and just saving the push) part for subsequent manual action.
Anyway, let me know if the Rearrange_Build_and_Source branch seems to be a good direction or not. We can delete it if not.

The ant build process should still work fine, I don't know if there's much else to say. Pascal set that up ages ago, and I added the PEAR package support since the package depended on other PEAR packages at the time. If the repository moved to the newer PEAR-installable package format, using a Pyrus -managed package.xml (like what Zend Framework 2 is doing), having a src directory would be ideal.
I really would prefer to keep the source inside a source or src directory, as this allows people to use the phpCAS lib as a submodule, and simply grab the files they need.

@adam: There are 3 ant tasks to execute. You however require a small setup file "build.properties" with proper config. An example is in the root dir. Then you execute "ant dist" "ant upload" "ant makeCurrentSymlink". There also the "clean" and "cleanAll" tasks to remove any previous packaging etc.
The "dist" pretty much does the packaging, doc generation and also executes the makepackage in /utils to get the PEAR package. The "upload" and "makeCurrentSymlink" are simple scp and ssh commands excuted to push the binaries to the jasig download space.
I think your idea of making the release tagging and automating the stuff before does sound like a nice idea. Also moving the code does seem like a good idea if we can increase comaptibility and better PEAR support. Before doing big stuff on the code we should really check that we have all branches integrated if possible so that we limit the impact on our coding. The Autoloader and also the License branches could be affected.

PEAR
Brett, Joachim, I assumed that the PEAR package was being built for submission into the PEAR package repository, however searching for CAS on pear.php.net returns no results. From Brett's last comment it sounds like the PEAR package was just there to manage dependencies that no longer exist. Is there any utility in building the PEAR package currently? If not, should we just remove everything related to PEAR?
From the other side, should we work toward distributing phpCAS via the PEAR package repository?
File/Directory Structure
If there is utility in keeping the source/ directory, my suggestion would be to add a CAS.php file to the project root that has one line, <?php require_once(dirname(__FILE__).'/source/CAS.php); ?> and have any releases packages maintain the same directory structure as the source repository:
phpCAS/                 # project root, name variable.

phpCAS/CAS.php          # in both source and built packages
                        #   <?php require_once(dirname(__FILE__).'/source/CAS.php); ?>

phpCAS/doc/             # in both source and built packages

phpCAS/doc/api/         # only in built packages

phpCAS/doc/examples/    # in both source and built packages

phpCAS/doc/index.html   # In source control, URL is to
                        #   http://downloads.jasig.org/cas-clients/php/1.2.2/docs/api/
                        # in built packages, this is replaced with a relative url to
                        #   api/

phpCAS/README.md        # in both source and built packages

phpCAS/NOTICE           # in both source and built packages

phpCAS/source/          # in both source and built packages

phpCAS/source/CAS.php   # in both source and built packages
                        # When tagging releases, replace
                        #   /define\('PHPCAS_VERSION', '[^']*'\);/
                        # with
                        #   define('PHPCAS_VERSION', '1.3.0');
                        # or whatever the correct string is.

phpCAS/source/CAS/      # in both source and built packages

phpCAS/test/            # only in source? or should it be both?

phpCAS/util/            # only in source? or should it be both?

Having this structure for both the source repository and the release packages would allow any projects that use include('CAS/CAS.php'); from packaged releases to continue to work, as well as those who use include('phpcas/source/CAS.php'); from repository clones. As well, this structure would allow the release-tag in the git repository to match the equivalent release package, with only the addition of the docs/api/ directory, the URL to the API docs in doc/index.html and the [optional] removal of the test/ and util/ directories.
Release/tagging process
Here is a high-level overview of what I'm thinking for the release process (to be written into the ant tasks). Basically, we'd keep mostly the same process (B and D), but with the addition of the version ids to the source repository and the git tag (A and C).
Build locally
A. Prep the source repository
Update the PHPCAS_VERSION and API docs urls, then make commits. For better error handling than is listed below, the current commit id could be noted and if errors occur, the repository state could be reset back to that commit id.

Verify that there are no uncommitted changes before going further: git status --porcelain
Search and replace /define\('PHPCAS_VERSION', '[^']*'\);/  with define('PHPCAS_VERSION', '1.3.0'); in source/CAS.php
Search and replace the /href="http:\/\/downloads.jasig.org\/cas-clients\/php/[^\/]\/docs\/api\/"/ with the string for the new version in docs/index.html
Commit the search and replace: git commit -a -m "Prepped release 1.3.0."
Tag the release: git tag -m "phpCAS release tag for 1.3.0.

B. Create the dist/

Copy files to the dist/ directory/
Build the API docs.
Search and replace the /href="http:\/\/downloads.jasig.org\/cas-clients\/php/[^\/]\/docs\/api\/"/ with href="api/" in docs/index.html
Create tarball.

C. Move the PHPCAS_VERSION forward the source repository.
These steps will allow differentiation between tagged releases and those working off a source branch with additional work. I'm using 1.3.0+ in this example, but something else like dev-1.3.0 could be used instead.

Search and replace /define\('PHPCAS_VERSION', '[^']*'\);/  with define('PHPCAS_VERSION', '1.3.0+'); in source/CAS.php
Commit the search and replace: git commit -a -m "Updated version tag past the tagged release."

D. Make the PEAR package ?
Upload/Push

Push the tag to the repository:  git push origin refs/tags/1.3.0 master
Upload to downloads.jasig.org

PEAR

however searching for CAS on pear.php.net returns no results.

The PEAR project has made it possible for anyone to distribute PEAR-installable libraries, without having code in the official PEAR repository.

From Brett's last comment it sounds like the PEAR package was just there to manage dependencies that no longer exist.

I think you're right, it looks like there are no dependencies on external PEAR packages now.

Is there any utility in building the PEAR package currently? If not, should we just remove everything related to PEAR?

Well, there are two benefits I can think of. The PEAR/Pyrus installer verifies that the end-user has all the PHP extensions necessary, and provides a relatively easy upgrade process — but that's the only benefits I can think of.

From the other side, should we work toward distributing phpCAS via the PEAR package repository?

The PEAR project has very strict coding standards which would take a bit of work to get the code to meet (run phpcs on it to see what I mean). The other requirement would be renaming the classes so we're PSR-0 compliant. The class names should map exactly to file names to support standard autoloading practices.
These changes would take quite a bit of work and would certainly break backwards-compatibility. I think it'd be a great goal to try and follow the standards many projects use for their own libraries, but not something I'd try and accomplish right away.

Having a PEAR package would be great for people using phpcas. Packages could depend directly on phpcas.
I think the PSR-0 is not a big issue. I have already started converting phpcas to the autoloader i just snatched from simplecas ;) It's compatible to PSR-0 as much as i can see. The work is #8 and branch PHPCAS-125
The phpcs is definately a challenge with over 2k error. Most of them indenting but it's still a lot ....
@adamfranco: I think your release process looks fine. Do we want to stick with ant build script?

Since we are not doing anything with the PEAR package.xml right now (it gets built, but seems to never get uploaded or included in the distributed tarball) would it be OK if we removed it from the build process and start a new issue for adding PEAR as a distribution/installation option? I feel like this is something we should take some time to do right rather than trying to shoehorn in now. Getting rid of the existing package.xml generation would make it a bit easier to streamline the build process.
The big backward-compatibility hurdle we will face with being fully PSR-0 compliant is that the static API class is named phpCAS while its file is CAS.php and everything other class is named CAS_Xxxx. I don't have any good ideas on how to resolve that, but maybe somehow this could be sorted out for a 2.0 release if it would make the pain worth the utility.
@jfritschi I'm fine with sticking with ant or using a different build process. I haven't worked much with ant, make, or any other build tools, so I don't have much of an opinion. I figure out how to use whichever tool you choose.
Summary of tasks.
Assuming an affirmative for short-term removal of PEAR support, here are the tasks remaining to finish off this issue:

Create a new issue for adding meaningful PEAR support.
Update the initial PHPCAS_VERSION tag in the source and the API doc URL in docs/index.html
Add a CAS.php file with <?php require_once(dirname(__FILE__).'/source/CAS.php); ?> to the root of the project directory.
Move all build-tools to util/
Rework the built targets to fit the directory structure and build-process above (with the existing upload and makeCurrentSymlink targets remaining as they are).
Finish #8 and verify that the build process still works
Finish #5 and verify that the required LICENSE and NOTES files are included in the tarball.

@jfritschi, @saltybeagle, Let me know if you are in agreement with this path (and if we should continue with ant or something else) and I will start a new branch with the work.

@adamfranco Your proposal sounds good to me.

@adamfranco: Sounds fine. Please go ahead. If you want me to help with any specific tasks please drop me a note.

I've completed the updates to the build process on the PHPCAS-12_Rearrange_Build branch.
The build process now looks like:
ant prepare   # The default action, tags, packages, and commits to the local repository
ant push      # Push the new commits and tags to the origin repository (github)
ant upload    # Upload to jasig
ant makeCurrentSymlink # Set the symbolic link on the jasig site.

The ant prepare target is equivalent to ant tag && ant dist && ant markdev.
To revert the commits and tag additions added in the ant tag and ant markdev
targets, use the new ant revert target. This should not be done after pushing.
Please give the build process a try and make sure that everything works for you -- other than actually pushing a new release :-). Running ant prepare is safe and can be followed by ant revert to get rid of the added commits and tag in your local repository.

Great work Adam. Works great.  :D
I just added a small patch to fix two small issues.


Added sdk changes for meetings notification sample

Build status - All builds passed
https://github.com/OfficeDev/Microsoft-Teams-Samples/actions/runs/4730265751


Error printing out confusion matrix

Hi, I'm encountering errors when trying to print out the confusion matrix when training diploSHIC.
Minimal code:
If I simply want to run the training command on mosquito simulation data, as provided in your tutorial, but also outputting the confusion matrix:
diploSHIC train trainingSets/ trainingSets/ bfsModel --confusionFile ConfusionMatrix
I get the following error message:
Traceback (most recent call last):
  File "/ceph/users/mhartfield/.conda/envs/diploshic/bin/diploSHIC", line 537, in <module>
    from misc import plot_confusion_matrix
ModuleNotFoundError: No module named 'misc'

I looked at the 'diploSHIC' python file in the repo and there is no 'import misc' command; I added such a command to the end of the other 'import' commands but there is still an error message.
Program was run on a linux-based cluster.
Update - I realised that I added the 'import misc' command to the downloaded version of diploSHIC, but not the installed version in the conda env on the server. I manually edited that file but still get an error:
Traceback (most recent call last):
  File "/ceph/users/mhartfield/.conda/envs/diploshic/bin/diploSHIC", line 3, in <module>
    import argparse, time, sys, subprocess, misc
ModuleNotFoundError: No module named 'misc'

Hi Matt, I was able to reproduce this in a fresh env and installation. I am guessing testing the confusion matrix plotting got lost in some downstream changes to the packaging.
If you change the import at line 537 to from diploshic.misc import plot_confusion_matrix and then re-install that should fix it.
I am not sure if you are installing diploshic from source or through pip but the easiest and quickest fix will be to download the repo -- make this one line change -- and then re-install from source. In the meantime I will make a PR to get it fixed in the master branch and then propagated to the versions of diploshic on PyPI


Bump upper bounds for ghc-9.6.1.

I suppressed a warning with ghc >=9.2 in the test suite then loosened bounds to get compilation going first for ghc-9.4.5 and then for ghc-9.6.1.
$ cabal test all --test-show-details=always
Resolving dependencies...
Build profile: -w ghc-9.6.1 -O1
In order, the following will be built (use -v for more details):
 - composite-base-<IP_ADDRESS> (lib) (configuration changed)
 - composite-base-<IP_ADDRESS> (test:composite-base-test) (configuration changed)
Configuring library for composite-base-<IP_ADDRESS>..
Preprocessing library for composite-base-<IP_ADDRESS>..
Building library for composite-base-<IP_ADDRESS>..
Configuring test suite 'composite-base-test' for composite-base-<IP_ADDRESS>..
Preprocessing test suite 'composite-base-test' for composite-base-<IP_ADDRESS>..
Building test suite 'composite-base-test' for composite-base-<IP_ADDRESS>..
Running 1 test suites...
Test suite composite-base-test: RUNNING...

Basic record utilities
  Supports construction and deconstruction of a Rec Identity [✔]
  Supports construction and deconstruction of a Rec f [✔]
  Supports construction and deconstruction of a Rec f (Contravariant) [✔]
  Supports lensing in a Rec Identity [✔]
  Supports lensing in a Rec Maybe [✔]
  Supports lensing in a Rec Predicate [✔]
withLensesAndProxies
  works for simple fields [✔]
  works for declaration blocks with non-fields in them [✔]
  works with parameterized fields [✔]
withOpticsAndProxies
  works for simple fields [✔]

Finished in 0.0032 seconds
10 examples, 0 failures

Test suite composite-base-test: PASS

As a Hackage trustee I made a matching revision: https://hackage.haskell.org/package/composite-base-<IP_ADDRESS>

Thanks @Bodigrim for adding a hackage revision. With that I can remove these allow-newer exceptions:
allow-newer:
  -- https://github.com/composite-hs/composite-base/pull/7 has not merged.
  -- Latest is composite-base-<IP_ADDRESS>, uploaded to hackage on 2022-12-15.
  , composite-base:lens
  , composite-base:template-haskell
  , composite-base:text


Fix commits

checked out the commit for fixing logging e8af7db - Renan Campos : Fix logging panic in awsDataGather into a new branch
cherry picked commit for egress firewall 324eaa8 - Rewant Soni : Egress Firewall
cherry picked commit for security context 075a531 - Rohan Gupta : Updated security context to remove unwanted privileges and capabilities

@rewantsoni
We have reset the Head of the main branch to remove all of the additional commits and reintroduced the correct commit via https://github.com/red-hat-storage/ocs-osd-deployer/pull/261. I think there is no need for this PR anymore.
Can you please close it?


visualize object references with lines when object is selected!?

instead of having to wait for the hover-popup and trying to figure out which objects the links refer to!?

the graph-view solves this sufficiently


Attempt to add cross-platform builds

Also

wrote down how I tried to get set up for local development on macOS (failed to get glide to run, so far, it just panics. I have golang 1.10).
worked around the fact that owner, group or mode are not applicable to Windows filesystems.

Superceded by #585.


Feature: Support Cucumber usage reporter

The problem
I find it hard to find out if I have any unused steps
A solution
When running bddgen export it would be nice to see a count next to the step name to locate any unused ones

This is available as the usage reporter of cucumber.js, but It seems that it isn't supported yet even after the recent addition of cucumber reports on playwright-bdd https://vitalets.github.io/playwright-bdd/#/reporters/cucumber

Good point, we should definitely support usage reporter. The reason why it is not implemented yet - it relies on step definitions. To have them in Playwright reporter output, playwright-bdd should re-read step definition files once again in the reporter process or pass them as a metadata.
Another option as a lightweight solution - enhance bddgen export command to output unused steps, e.g. bddgen export --unused-steps. The output will not contain duration of each step, but the command will run very fast, because it does not  actually run tests.

Maybe lightweight solution first and support usage reporter further down the line?

Partially related to https://github.com/vitalets/playwright-bdd/issues/53

Flag --unused-steps released in v6.1.0. Now you can run:
npx bddgen export --unused-steps

Output:
Using config: playwright.config.ts
List of unused steps (1):
* Then I see in title {string}

Currently unused steps are displayed without file location, will add it in the next release.
Keep this issue open for Cucumber usage reporter.


Table metedata cann't sink into external  elasticsearch

Describe the issue
With v0.8.45，docker-compose running,   docker-compose file is copied from docker-compose-without-neo4j.quickstart.yml,  and delete the elasticsearch configuration and replace it with the external elasticsearch7.9.3.
when execute datahub ingest -c recipe.yml command, many errors occur on datahub-gms console like this:
09:34:32.849 [I/O dispatcher 1] ERROR c.l.m.s.e.update.BulkListener:25 - Failed to feed bulk request. Number of events: 80 Took time ms: -1 Message: failure in bulk execution:
[0]: index [datasetindex_v2], type [_doc], id [urn%3Ali%3Adataset%3A%28urn%3Ali%3AdataPlatform%3Amysql%2Csys.x%24schema_table_statistics_with_buffer%2CPROD%29], message [[datasetindex_v2/qKet_B5LQdqA0DfGt2QoLQ][[datasetindex_v2][0]] ElasticsearchException[Elasticsearch exception [type=document_missing_exception, reason=[_doc][urn%3Ali%3Adataset%3A%28urn%3Ali%3AdataPlatform%3Amysql%2Csys.x%24schema_table_statistics_with_buffer%2CPROD%29]: document missing]]]
[1]: index [datasetindex_v2], type [_doc], id [urn%3Ali%3Adataset%3A%28urn%3Ali%3AdataPlatform%3Amysql%2Csys.x%24schema_tables_with_full_table_scans%2CPROD%29], message [[datasetindex_v2/qKet_B5LQdqA0DfGt2QoLQ][[datasetindex_v2][0]] ElasticsearchException[Elasticsearch exception [type=document_missing_exception, reason=[_doc][urn%3Ali%3Adataset%3A%28urn%3Ali%3AdataPlatform%3Amysql%2Csys.x%24schema_tables_with_full_table_scans%2CPROD%29]: document missing]]]
......
To the end, Only one table sinked into the external  elasticsearch, other tables doesn't sinked into the the external  elasticsearch.

@qiusheng0755 does it work for you when you use default elasticsearch without any changes in the compose file?

yes,  it works successful when use default elasticsearch without any changes in the compose file.  The failure  happen on use the external elasticsearch7.9.3

I'm not sure if this is some sort of general issue with elasticsearch itself. I started a thread on troubleshoot channel because just today I had started to face the same issue with delta-lake as a source.

I tried to use the external elasticsearch7.12.0, but the problem still exists.

This issue has been resolved. The reason is that when external es is used, the contents in the MySQL table are not cleaned up. When truncate table metadata_aspect_v2, data can be written to the es normally.


[5.4] Fix validating array of input type file

   <form method="post" action="{{ route('test.store') }}" enctype="multipart/form-data">                                             {{csrf_field()}}                                             <input type="file" name="profile[ar]">                                             <input type="file" name="profile[en]">                                             <input type="submit" value="create">                                             </form>
then if we tried this in a request file or with validate method ,
[ 'profile.*' => 'required|image']
the validation will pass on submit because of :-
filterFiles method removes the null elements, so in Validation/Validation.php constructor  if we made dd($data) we will find that our files elements aren't presented in the data array , so in addRules method if we made dd($response) we will find our rules attribute and implicitAttributes are empty .
so finally in Http/Request.php passes() method , the two loops on $this->rules , and on $this->after will not be executed unless there's another attributes other than files attributes .
and the array validation with files upload will always pass .
try the same above steps after , initializing the $files[$key] with empty array .
note :- it should be initialized as array , so that it doesn't break Symfony FileBag.php the set($key, $value) method and throws an exception ,for in case we mixed , array file validation , with single file validation like that :-
['profile.*' => 'required|image',
'single' => 'required|image' ]
this pull request will fix this problem  :-
['profile.ar'  => 'required|image',
'profile.en' => 'required|image']
as it will be pain for writing all upload files like that .

@themsaid not sure this looks right?

@Te7a-Houdini sorry i don't get the problem, can you please mention some details on how to replicate? You have two file inputs and this rule [ 'profile.*' => 'required|image'], where's the issue?

@themsaid try to click on submit without uploading any file , it will pass the validation

Yes it will because 'profile.*' => 'required|image' requires the presence of an array member, you need something like profile => 'required|array', that way the validator will error since there are no array members.

it also passed after trying this ,

'profile.*' => 'required|array|image',

Not profile.*, but profile. You need to make sure the profile attribute is an array and that it's not empty.
Your rule set need to look like:
'profile' => 'required|array',
'profile.*' => 'required|image'

@themsaid  it worked thank you


splitting string with original regex in ie11 fails

The original implementation of the split regex causes the classname in IE11 to be splitted for every letter.
Example:
classArray("test") returns ['t','e','s','t',] instead of ['test']

Related https://github.com/d3/d3-dispatch/issues/18
Note that d3-selection has dropped support for older browsers including IE, see https://github.com/d3/d3-selection/releases/tag/v2.0.0


bug(windows): Failing soak tests

Describe the bug
When I leave the client up on my VM overnight, it stops working after a while
To Reproduce

Start the client
Check ifconfig.net to make sure we're getting the gateway's IP
Lock the computer and leave it overnight (Locking and unlocking does not reproduce this bug)
Check ifconfig again in the morning - It never connects

Expected behavior
Expect ifconfig to load quickly and show the gateway IP as long as Firezone is running
Screenshots / Logs
I have some logs I'll read through.
Platform (please complete the following information):

Firezone Version 079b4e7
OS: Windows Server 2022

Additional context
Hypotheses:

Locking the computer (No)
Putting the computer to sleep (Probably not)
Sheer time (No)
Idle time (Needs testing)

I set up a program with reqwest to check ifconfig.net every 90 seconds and let me know when the result changes. Maybe this will give me a clue how long it takes to reproduce.

Maybe it only replicates if I'm not sending traffic through the tunnel? 🤔

I think if the tunnel is idle for about 1 hour, this might replicate. There was a bug in my soak testing code, so I'm leaving it run again overnight.

61acb23 failed between 1531 and 2296. (That is, a request succeeded after sleeping for 1,531 seconds, but the following request after 2,296 seconds failed)

Next step: Check whether this affects CIDR resources too (I'd been doing ifconfig.net) and check whether it might be my wintun worker thread getting stuck somewhere.

Failed with an interval of 26151
So I don't think the interval is anything consistent like a timeout. It can fail within an hour or it can work okay for a few hours at a time before failing.

Haven't worked on this for at least a week, it's easy to re-open, and we'll probably get better details once it goes to beta.


See connected device

I can't find a way to see a list of all connected devices in Luci, where is it?
I just see active dhcp leases.
There should also be the possibility to check wifi-only connected devices, imho.

Wifi clients are listed in the main status page as well in the wireless settings overview page.

what about cable connected clients?

You can find this information in the ARP table.


[wip] Wesnoth MacOS

Motivation for this change
These changes get Wesnoth building on MacOS.
However, graphics aren't being displayed correctly! The menu looks like this:

Does anyone have ideas on how to fix this? Currently I'm out of things to try.
/cc @LnL7 @copumpkin
Console log looks normal:
Battle for Wesnoth v1.12.6
Started on Wed Nov 15 08:25:00 2017

Fontconfig error: Cannot load default config file

Data directory: /nix/store/1w5vz4p6gp08xsk2w7a7h8g5hxkfb1zn-wesnoth-1.12.6/share/wesnoth
User configuration directory: /Users/mbauer/.config/wesnoth
User data directory: /Users/mbauer/.local/share/wesnoth/1.12
Cache directory: /Users/mbauer/.cache/wesnoth
Checking video mode: 800x600x32...
setting mode to 800x600x32

Interesting but not sure what would cause that! Perhaps ask the Wesnoth folks if they've seen this before stemming from some misconfiguration in the build somewhere?

Yeah, I'll see if I can find anything on it. I remember something similar happening where an app would basically just assume that you are in a .app bundle if you were running macOS and want to get images and resources from there. Weird that there's no errors though.
Also: SDL tests need to be disabled to work on Hydra (something about being headless). It's just passing --disable-sdltest and --disable-smpegtest to configureFlags for them to work. Is there a way to do that for everything SDL-based derivation? (so far I've been adding them manually). Most likely Wesnoth will need it to to work correctly.

Okay I think this is ready to merge. Still have the graphics issue but haven't found time to get it working.


Behavior switching w/ Become() w/in the context of a DomainEventSubscriber

I am trying to build a draft form of a durable projection system for Akkatecture. I am wanting to use some of the concept of how the DomainEventSubscriber was built to do this.  However, I would also like to be able to implement behavior switching (to enable a projector manager to 'play', 'pause' , 'stop' projectors and possibly other administrative functions.
Would it be possible to implement behavior switching with the way that the DomainEventSubscriber creates the Receive<> methods ?  That is, I know that each Behavior (private void SomeBehavior() method ) has to have its own set of Receive<> methods to describe its behavior.  How would I go about populating the Behavior methods with the Receive<> methods they need ?  Would a call to a reflection based "CreateHandlers" method be needed at the top of each Behavior method be required ?  For example, something like this ?
        private void Playing()
        {
            CreateHandlers();

            Command<PauseReactorCmd>(cmd =>
            {
                Become(Paused);
                Context.Parent.Tell(new PauseReactorAck());

            });

            Command<SomeOtherMsg>(cmd => {}); ...

        }

This is an interesting idea. I'd like to learn more what you hope to accomplish with that functionality.
I think it would not be necessary to use reflection to add more methods. The reflection in use by the library allows developers to denote their custom Event types and then have Receive methods invoked on them. You could write your own boilerplate functions in a new child class of DomainEventSubscriber. It would still operate as DomainEventSubscriber does now, but then you'd also have the state machine-related functions you want there too.
I will say that the resumeable projections I've created, I ran in an entirely different process. It used a "shallow", read-only Actor System in order to query the Event Journal via Akka.Persistence.Query. I did not use event subscribers for this purpose, though I know it's possible.

Reach out if you have more thoughts on this.


Unpickle failing from missing field in json

I'm running into a case where upickle is consistently throwing an exception while trying to unpickle a case class like
case class MyThing(uuid1: UUID, uuid2: UUID, name: String, boolOpt: Option[Boolean],
                   properties: Map[String, String] = Map.empty, uuid: UUID = UUID.randomUUID())

When the properties map has something in it, it's fine, but empty maps blow up ("Key missing: properties").
I have a pretty minimal example here: https://github.com/CodeMettle/upickle-boom
The interesting thing I've noticed is that if the test is only one project instead of two, it runs fine.

Thanks for the repro! I'll take a look when I have the time...

The readme in the project says it, but it bears repeating - after enough changes to and incremental compiles of the model project, things work fine. So something's weird, and I don't know that it's something you're doing or something in the scala compiler, but I'll leave it up to you. In the time being I just make fake changes and recompile a few times until it starts working.

I'm having the same issue...  I whipped up another test using autowire because it resembled my usecase (I am only using upickle as the serializer with autowire):
import utest._
import autowire._
import upickle.default._

import scala.concurrent.ExecutionContext.Implicits.global

case class BooleanWrapper(bool: Boolean = false)
case class OptionBoolean(optBool: Option[Boolean] = Some(false))

trait BooleanApi {
  def show(bw: BooleanWrapper) = bw.toString
  def optionShow(optBw: OptionBoolean) = optBw.toString
}

object BooleanServer extends autowire.Server[String, Reader, Writer] {
  def write[Result: Writer](r: Result) = upickle.default.write(r)
  def read[Result: Reader](p: String) = upickle.default.read[Result](p)

  def routes = BooleanServer.route[BooleanApi](new BooleanApi {})
}

object BooleanClient extends autowire.Client[String, Reader, Writer] {
  def write[Result: Writer](r: Result) = upickle.default.write(r)
  def read[Result: Reader](p: String) = upickle.default.read[Result](p)

  override def doCall(req: Request) = {
    println(req)
    BooleanServer.routes.apply(req)
  }
}

object BooleanWrapperTest extends TestSuite {
  val tests = TestSuite {
    "invalid input when using default" - {
      BooleanClient[BooleanApi].show(BooleanWrapper()).call().foreach(println)
    }
    "invalid input even when explicitly provided value is same as default" - {
      BooleanClient[BooleanApi].show(BooleanWrapper(false)).call().foreach(println)
    }
    "valid input if provided value is not the same as default" - {
      BooleanClient[BooleanApi].show(BooleanWrapper(true)).call().foreach(println)
    }
    "invalid input when using wrapped default" - {
      BooleanClient[BooleanApi].optionShow(OptionBoolean()).call().foreach(println)
    }
    "invalid input even when explicitly provided wrapped value is same as default" - {
      BooleanClient[BooleanApi].optionShow(OptionBoolean(Some(false))).call().foreach(println)
    }
    "valid input if provided wrapped value is not the same as default" - {
      BooleanClient[BooleanApi].optionShow(OptionBoolean(Some(true))).call().foreach(println)
    }
  }

}

Another quick note on this - I forked upickle and tried to reproduce the issue in the existing examples. in a test and could not using Scala 2.10.  Unfortunately, I could not get the tests to run utilizing Scala 2.11 due to my inability to get past an unresolved dependency on the derive project (building it and publishing locally did not seem to help).

@matthewpflueger try bumping the version in project/repo.scala to a SNAPSHOT; otherwise SBT gets confused

Thanks, that worked.  Unfortunately, I could not reproduce in the existing example tests.  I put the test above in a working project which fails here: https://github.com/matthewpflueger/upickle-test

Seems fixed by https://github.com/Voltir/upickle/commit/832756d3d8e1083ec00af6806f120b76f43f26ef. Thanks @Voltir!

#203 seems the same issue. Sometimes it goes out, very frustrating.
Now I use 0.4.4, scala 2.11.8.


FIX: Allow for key called slash

(cherry picked from commit b0a8ad79248676f7d03f39d89cc8322dd3413973)

@ironman-machine go

Hello @LaurenSpiegel
Starting end to end procedure using the following payload:
{"REPO_NAME": "S3", "SCALITY_S3_BRANCH": "backport/slashKey", "DEFAULT_BRANCH": "rel/6.2.5"}
Please follow http://ci.ironmann.io/gh/scality/Integration/8875 for CI status.

end to end passed http://ci.ironmann.io/gh/scality/Integration/8875


Proposal: Decouple vertice/edge store from graphs

Hey there,
Let me start off by saying a big thank you for releasing this as open source. I really like the use of hashes for identifying vertices as it allowes for more flexibility.

I was attempting to split out the storage/retrieval of vertices/edges to a Store interface and eventually implement a sql store (mainly to figure out how horrible the performance would be). While doing so, I bumped into a couple of things I ended up changing that I wasn't really comfortable with and wanted to ask a couple of questions if that's ok.
At this point can I just say that this is meant as critique, but rather as genuine questions from someone who hasn't spent much time dealing with graphs. I'm just trying to understand the thinking behind the design decisions and avoid making mistakes because I did not understand or think of something.
This PR is a work in progress and is mainly to get a discussion started. In its current state it only includes an in-memory store as a POC, but tests should be all passing. (Memory store tests are needed.)
I'd be more than happy to work with you on getting this right and merging it upstream, but I totally understand if this is not something you'd be interested in; in which case please feel free to close this PR at any point. :)

So, couple of questions:

What's the need for the un/directed.edges attribute? From what I can tell, in both directed and undirected it's the same as outEdges. I've kinda removed it as I wasn't really sure on what the usecase was.

Currently the Edge[T] struct contains the source/target vertices. Besides a more developer-friendly API, is there a reason for the source/targets to not just be hashes? I played around with using Edge[K] instead, as it greatly simplifies the Store implementations.

Do you have any plans currently on adding extra attributes to the Edge besides weight? ie. Labels maybe?

The readme mentions that multigraphs are not supported. Is this something you are planning or would be interested in? It would pose a number of interesting questions around the API for both the graph and the Store.

Thank you very much in advance!
Regards, ~geoah

Hi, thanks for your proposal and your questions! I'm happy to answer them.

At this point, egdes only exists for historical reasons. I decided to maintain an outEdges map explicitly for outgoing edges, and an edges map containing all edges. I wasn't sure whether these two maps would be identical, but with the current implementation, they are. I haven't optimized the library for better time and space efficiency yet, but one of the first steps definitely would be to remove edges.

The reason behind this is only the more developer-friendly API. This way, you can directly access the underlying vertex object without looking it up via its hash. I think this works well enough for many if not most use cases, but I'm also aware that this leaves room for optimization.

Absolutely! I'll create an issue for adding labels.

I would love to support multigraphs in theory, but it makes everything much more complicated. If you're designing a storage API, you don't need to have multigraphs in mind.

Opened #13 for edge labels.

Hey @dominikbraun, thank you for your reply and answering my questions.
Do you think splitting out the store interface would be of use to this library or would it be outside of its scope?
If it’s something you would consider, when you have some spare time I’d appreciate some feedback and suggestions on the current approach and I'd be more than happy to refactor it.

Making the store implementation flexible and would be useful indeed. I think it might make sense to prescribe a store API and provide an in-memory default implementation like the current one - anything beyond that can then be implemented by the user or provided by an extra library.
I'll take a look at your approach later today 🙂

So I took a look at your proposal and I like the design so far. I only have three thoughts or possible improvements in mind:

I'd love to default to an in-memory store and accept a custom store as a functional option. At the moment, creating a graph would look something like this:

graph.NewWithStore(graph.IntHash, graph.NewMemoryStore(graph.IntHash), graph.Weighted())

That IntHash part is kind of repetitive. I would prefer something like this:
graph.New(graph.IntHash(), graph.Weighted())

And with a custom store:
graph.New(graph.IntHash(), graph.Weighted(), graph.WithStore(myStore))

The problem is that there already are functional options for traits. To implement my proposed solution, we would need to create an options type for the functional options API, and read the fields of these options into g.traits and g.store when creating a graph. Would you see any problems with this approach?

We should try to keep the Store interface as small as possible. I didn't check it in detail yet, but maybe the graph can build the result of something like GetEdgeTargetHashes itself using GetEdgeTargets? Perhaps there is an opportunity to remove a method if it is only used once or twice and the result can be built ourselves.

The naming of variables and functions, not just in your PR but in the entire codebase, needs to be unified a bit. For example, GetEdgeTargets returns a variable sourceEdgesArray - for the sake of readability, I'd argue that either the variable name should be edgeTargets or the function name should be sourcesEdges. This is a nitpick though.

All in all, I'm quite a fan of this feature!

That's really nice to hear. :D

I struggled with this a bit and the issue I had was that in order for me to add a Store[K, T] in the traits, I had to make the traits struct itself generic which would result in having to instantiate all options with the correct types. (ie graph.Directed[int, int]() which would be horrible. -- I'll revisit this and try to get them into the existing options, hopefully without much reflection.

That makes sense, at this point I tried to lift and shift as much code as possible to keep things simple. -- I'll check what can be consolidated to reduce the surface of the interface without affecting performance too much.

Couldn't agree more. Naming can definitely be improved in a lot of places to make things more clear and consistent.

Let me play around with this a bit more and I'll ping you with some updates!

I see... Making traits generic comes with a huge overhead and won't be a viable solution. So there would be two possibilities:

Include the Hash function in Store, only accept a Store, and provide an InMemory function that takes a hash function and returns a generic in-memory store. Example:

type Store[K comparable, T any] interface {
	GetVertex(K) T
}

func InMemory[K comparable, T any](hash Hash[K, T]) Store[K, T] {
	return inMemoryStore[K, T]{
                hash: hash,
        }
}

func New[K comparable, T any](store Store[K, T], options ...func(*traits)) Graph[K, T] {
        // ...
}

The New call would look as follows:
g := graph.New(graph.InMemory(graph.IntHash), graph.Weighted())

If somebody wanted to use a custom data type, they could still use the generic in-memory store, and if somebody wanted to use a custom store, they could still use the pre-defined hashing functions.

Create a NewWithStore function as you already did. Sorry for bothering you with design challenges that you've already considered 🤣

The disadvantage of the NewWithStore function is that the hashing function needs to be passed twice. To circumvent this, we could go for a hybrid approach where the New function stays as it is, and the NewWithStore function accepts a store and we provide an InMemory wrapper function as shown above. The calls would look as follows:
g := graph.New(graph.IntHash, graph.Weighted())
g := graph.NewWithStore(graph.InMemory(graph.IntHash), graph.Weighted())

New could then just call NewWithStore with the in-memory store. What do you think of this approach?

Hey @dominikbraun, quick update.

Effing generics...

I noticed that we don't really need the hashing function in the store so did some refactoring to remove it, but even then, the graph.New() is still a pain in the butt.
We still can't put the Store[K, T] on the trait struct, and now because we don't provide the hash function for go to infer infer K and T, instead of graph.NewMemoryStore(graph.IntHash) we need to do graph.NewMemoryStore[int, int]().
I'll keep working on this and try some your suggestions.

In slightly better news, the Store interface looks a bit slimmer. Attempted to rename some of the methods to make them a bit more understandable and now we have the following:

type Store[K comparable, T any] interface {
	AddVertex(k K, t T) error // This allowed me to remove the need for the hashing function in the Store
	GetVertex(k K) (*T, bool)
	ListVertices() ([]K, bool) // Still thinking about this one vs GetAllVertexHashes()
	AddEdge(sourceHash, targetHash K, edge Edge[K]) error
	GetEdge(source, target K) (Edge[K], bool)
	GetEdgesBySource(source K) ([]Edge[K], bool)
	GetEdgesByTarget(target K) ([]Edge[K], bool)
}

Nice! Not needing the hashing function in Store makes things much simpler. To be honest, function calls like graph.New(graph.IntHash, graph.Directed()) and graph.NewWithStore(graph.IntHash, graph.InMemory(), graph.Directed() are fine for me. That way, you don't need to put the Store into the traits IMO.

@dominikbraun would have been nice if I had actually pushed the code I was talking about.
Pushed now, you should be able to check it out.
I've also added a bit more consistent error handling as it's really useful for when dealing with any non in-memory stores.

FYI: I've just merged PR #17 and released it as v0.5.0. This would need to be changed here as well.

Just a kudos for having NewWithStore and an interface, just what I was looking for (need serialization).

Hey @dominikbraun, just came back from vacation and I was picking this up again when I bumped into #25. I might wait until the dust has settled on that one as I think it will greatly simply decoupling the graph from the storage.

Ah, I've waited with #25 because I thought this PR and #25 would cause too many conflicts, but if you feel that #25 will simplify things here, we'll prioritize #25.

@dominikbraun I assume that the plan for #25 is that all other graph methods will be using the new API right?
In that case this PR will only have to refactor the basic graph implementation and not the other graph methods.

@dominikbraun I assume that the plan for #25 is that all other graph methods will be using the new API right? In that case this PR will only have to refactor the basic graph implementation and not the other graph methods.

Yap.

Re-opening to start with a clean thread :D

@geoah That seems to be the best solution since this PR is already a bit old and too large :-)


Car Control feature?

Hi, i have used this api in my car and it is running finr, but is it possible to send some commands so that we control some car features like, via sending any command from this api to car using obd-reader reader ,
i can trigger car horn or Head Lamps , please let me know if this is possible using this api or any other?

The API (obd-java-api) used in this project allows you to send any command you desire.

ok , i mean to say that i can turn on/off car Horn or Head Lamps via this api from android mobile app , please share any example or code ?

OBD-II PIDs are not meant for that. You must consult your car manufacturer to get the proprietary commands to execute.


Source delivery fixes

Changes

🐛 Fixed bug In the Source, when if the Retries Spec was set and an error response was sent by the sink, the system crashed because a miss configured backoff function

/kind  bug

Fixes #830

Release Note

🐛 Fixed bug In the Source, when if the Retries Spec was set and an error response was sent by the sink, the system crashed because a miss configured backoff function

/cherry-pick release-1.5

/retest

/test codecov/patch


Caching podman breaks installer CI and also nightly bundle creation

e2e-crc jobs are failing from installer side because of embedding podman binaries,  podman version -f json | jq -r .Client.Version on nightly provides v3.0.2-dev .

https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_installer/4674/pull-ci-openshift-installer-master-e2e-crc/1384211322379440128

INFO[2021-04-19T21:36:44Z] + download_podman 3.0.2-dev
INFO[2021-04-19T21:36:44Z] + local version=3.0.2-dev
INFO[2021-04-19T21:36:44Z] + mkdir -p podman-remote/linux
INFO[2021-04-19T21:36:44Z] + curl -L https://github.com/containers/podman/releases/download/v3.0.2-dev/podman-remote-static.tar.gz
INFO[2021-04-19T21:36:44Z] + tar -zx -C podman-remote/linux podman-remote-static
INFO[2021-04-19T21:36:44Z]   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
INFO[2021-04-19T21:36:44Z]                                  Dload  Upload   Total   Spent    Left  Speed
INFO[2021-04-19T21:36:44Z]
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100     9  100     9    0     0     63      0 --:--:-- --:--:-- --:--:--    64
INFO[2021-04-19T21:36:44Z]
INFO[2021-04-19T21:36:44Z] gzip: stdin: not in gzip format
INFO[2021-04-19T21:36:44Z] tar: Child returned status 1
INFO[2021-04-19T21:36:44Z] tar: Error is not recoverable: exiting now

https://github.com/containers/podman/releases/download/v3.0.2-dev/podman-remote-static.tar.gz

404 Not Found

Thanks for the ping, @gbraad.
@cevich may be able to help.

It is a dev-release, so this is kinda 'unsupported'. Though, removing a release is not necessary unless there is an issue with it.


gate calling of evp_method_id on having a non-zero name id

If a name is passed to EVP__fetch of the form: name1:name2:name3
The names are parsed on the separator ':' and added to the store, but during the lookup in inner_evp_generic_fetch, the subsequent search of the store uses the full name1:name2:name3 string, which fails lookup, and causes subsequent assertion failures in evp_method_id.
instead catch the failure in inner_evp_generic_fetch and return an error code if the name_id against a colon separated list of names fails.  This provides a graceful error return path without asserts, and leaves room for a future feature in which such formatted names can be parsed and searched for iteratively
Add a simple test to verify that providing a colon separated name results in an error indicating an invalid lookup.
Checklist

[x] documentation is added or updated
[x] tests are added or updated

This pull request is ready to merge


x/incentives - internal audit

The following are the remaining TODOs from the first pass. Would like to decide which of these we want to tackle as part of this audit and which we should just create issues for:

[ ] Fixed rewards estimation to work sometimes, but other times it panics Discussion
[ ] Optimize getToDistributeCoinsFromGauges Discussion
[ ] Fix hack here getLocksToDistributionWithMaxDuration Discussion
[ ] Have doDistributionSends have way more re-use with distribute internal Discussion
[ ] Need further explanation of checkFinishDistribution previous TODO Discussion
[ ] Make TestGetModuleToDistributeCoins TDD Discussion
[ ] Make TestGetModuleDistributedCoins TDD Discussion
[ ] Do we need to be concerned with case where this should be ActiveGauges? Discussion
[ ] Figure out what this number should be Discussion
[ ] Make TestGRPCToDistributeCoins table driven, or simpler Discussion
[ ] Clean up AfterEpochEnd Discussion
[ ] Switch more code to use userLocks and perpGaugeDesc Discussion
[ ] Delete all usages of this method (why?) Discussion
[ ] Why reset to 2 after postlaunch? Only 0 and 1 exist, and 1 is no longer used Discussion
[ ] Delete this comment if the below code satisfies the above request Discussion
[ ] x/epochs/simulation/genesis.go doesn't exist, what was this comment trying to say? Discussion


load js script including stage parameters into embedded html

Hey,
I define structures and representations within a js script. I want now to load this into an embedded HTML and manipulate/use the named representations, e.g. hide show whenever sb clicks on a button.
The first problem I run into: how do I correctly load the js script? I can't just <script src="ngl.js"></script> as the stage object was not defined yet.
As an example, I would like to load https://github.com/arose/ngl/blob/master/examples/scripts/representation/label.js into my HTML page (very simple, following: http://nglviewer.org/ngl/api/manual/usage/embedding.html). And then add the function to view/hide the surface as a click function outside of the .js file (in the HTML file).
Thanks for your help!
Cheers,
Johanna

As you've found - the code in https://github.com/arose/ngl/blob/master/examples/scripts/representation/label.js
is intended to be run once the NGL stage has been created, so the simplest thing to do is to wrap that in a function and only call it once the page is ready (you can use the DOMContentLoaded event as shown in embedding.html).
There are many ways to do this but a very simple example (if you just want to setup a single page with a fixed set of components, representations and buttons) would be something like
Main html page
...
<script src="ngl.js"></script>  <!-- This is the built NGL thing from github/wherever -->
<script src="myCode.js"></script> <!-- Your own code in this file -->
...

<input type="button" id="licoriceBtn">Toggle Licorice</input>
<input type="button" id="surfaceBtn">Toggle Surface</input>
...

Then inside myCode.js have a "DOMContentLoaded" listener, load the components, representations and define some functions for your buttons:

var reprs = {}

document.addEventListener("DOMContentLoaded", function () {
    var stage = new NGL.Stage("viewport");
    stage.loadFile("rcsb://1crn").then( function(c) {
       reprs.licorice = c.addRepresentation('licorice', {})
       reprs.surface = c.addRepresentation('surface', {})
       // Etc...
    })
});

document.getElementById('licoriceBtn').addEventListener('click', function() {
  reprs.licorice.setVisible(!reprs.licorice.getVisible())
})

document.getElementById('surfaceBtn').addEventListener('click', function() {
  reprs.surface.setVisible(!reprs.surface.getVisible())

When you find yourself repeating yourself a lot you can abstract out helper functions, or pickup a framework of your choice (react/vue/whatever) but for a minimal simple page something like the above would work fine.

Thanks for the really detailed answer - that helps!


[WIP] Fix the input metrics during insert into scenario

Be sure to do all of the following checklist to help us incorporate
your contribution quickly and easily:

[ ] Any interfaces changed?

[ ] Any backward compatibility impacted?

[ ] Document update required?

[ ] Testing done
Please provide details on
- Whether new unit test cases have been added or why no new tests are required?
- How it is tested? Please attach test report.
- Is it a performance related change? Please attach the performance test report.
- Any additional information to help reviewers in testing this change.

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/193/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/189/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/195/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/205/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/206/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/200/

Build Success with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/204/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/208/

@ravipesala , @kumarvishal09 , @kunal642 : please check

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/202/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/206/

retest this please

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/217/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/222/

Build Success with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/220/

retest this please

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/220/

Build Success with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/223/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/225/

retest this please

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/237/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/233/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/235/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/240/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/236/

Build Success with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/238/

@ravipesala : handled the comments please check

LGTM

LGTM


styling(fluidDialog): Use entire width of dialog.

Also increase width of "name" input and size of "description" input

The extra space disappears if you select the components with the longest name. Having us use the entire width of the dialog always would mean we would have to fix the width of the table. But I guess that would be okay

We could set a fixed width for the table, but this was a poorly worded issue. I'd say the goal is not to use the entire width, but have a longer name and description input, and have the table align right. Looks a bit messy the positioning now.


improve search logic

jump to first hit
just highlight but not select

Merged PR https://github.com/Caleydo/lineup.js/pull/169.


Committing the updated API docs for cat server into master branch.

Can one of the admins verify this patch?


Added share private domain feature

Can now add shared private domains across orgs.

Can you simplify bootstrap just a touch?


Hello, the same problem but i still have the private key.

    Hello, the same problem but i still have the private key.

The old copay app is allready updated on my iphone6SE
But it is still the old phone with the same data. But my copay wallet was gone without deleting it myself. I dont have the 12 word seed but only the privaye key.
Originally posted by @JDEJ19 in https://github.com/bitpay/wallet/issues/10824#issuecomment-1046096020

I helped a lot of with this issue to recover there’s perfectly send me a friend request on telegram let me help you with yours my telegram is BlackHatHacker111

Same thing happened to me but thanks to Blackhathacker111 who helped me message him on telegram his telegram username is Blackhathacker111

Same thing happened to me but thanks to Blackhathacker111 who helped me message him on telegram his telegram username is https://t.me/Blackhathacker111


Better error message for converting before fit

If a user forgets to call fit before calling convert they will get a confusing error message.  We should find a way to print a more helpful error message in a case such as a the following:
>>> import numpy as np
>>> from sklearn.linear_model  import LinearRegression
>>> from hummingbird.ml import convert

>>> X = np.random.rand(100, 200)
>>> X = np.array(X, dtype=np.float32)
>>> y = np.random.randint(2, size=100)

>>> l = LinearRegression( fit_intercept=True, normalize=False, copy_X=True, n_jobs=None   )

>>> l_hb = convert(l, 'torch')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.7/site-packages/hummingbird/ml/convert.py", line 252, in convert
    return _convert_sklearn(model, backend, test_input, device, extra_config)
  File "/usr/local/lib/python3.7/site-packages/hummingbird/ml/convert.py", line 80, in _convert_sklearn
    hb_model = topology_converter(topology, backend, device, extra_config=extra_config)
  File "/usr/local/lib/python3.7/site-packages/hummingbird/ml/_topology.py", line 76, in convert
    raise e
  File "/usr/local/lib/python3.7/site-packages/hummingbird/ml/_topology.py", line 68, in convert
    operator_map[operator.full_name] = converter(operator, device, extra_config)
  File "/usr/local/lib/python3.7/site-packages/hummingbird/ml/operator_converters/sklearn/linear.py", line 66, in convert_sklearn_linear_regression_model
    coefficients = operator.raw_operator.coef_.transpose().reshape(-1, 1).astype("float32")
AttributeError: 'LinearRegression' object has no attribute 'coef_'

>>> l.fit(X,y)
LinearRegression()
>>> l_hb = convert(l, 'torch')
>>> l_hb
<hummingbird.ml._container.PyTorchSklearnContainerRegression object at 0x137ce2610>

closed with #607


Custom text to frontmatter without underscores

Currently text is added with underscores. Can the underscore be removed please?

I will add the option to choose "Snake Case" or "Camel Case".

thanks, pal.
if you ever include you pay pal  or other version of donation button to the plugin description - coffee is on me!)


Sample code for viewport overlays?

Hi - we've been using OpenSeadragon to create tiled-image viewers (works great) but would like to enable toggling between different large images, following the viewport overlay example given at:
https://openseadragon.github.io/examples/ui-overlays/
The sample code featured there is a snippet that doesn't show two tiled image folders. Is there an expanded sample code that would more directly show how to create that with for example two large tile image folders located at different urls?
For a single image, we are using:
var testTiledImage1 = {
    Image: {
        xmlns: "http://schemas.microsoft.com/deepzoom/2008",
        Url: myurl,
        Format: "png",
        Overlap: "2",
        TileSize: "128",
        Size: {
            Width:  10000,
            Height: 13751
        }
    }
};

OpenSeaDragon({
    id: "openSeaDragon",
    prefixUrl: "//openseadragon.github.io/openseadragon/images/",
    animationTime: 1,
    blendTime: .5,
    constrainDuringPan: true,
    maxZoomPixelRatio: 5,
    tileSources: testTiledImage1
})

Can I technically just define another Image, e.g. car testTiledImage2 and then for OpenSeaDragon use tileSources: [testTiledImage1, testTiledImage2]?  Because that's what I've tried and hasn't worked, but want to make sure it's not some other issue.
Thanks!
Jonathan

When it's two tiled images, we don't call it overlays... Overlays are just for little bits of HTML or small UI images. You definitely can just pass an array of tile sources, but if you don't do any positioning, they'll be stacked directly on top of each other, so it may look like it didn't work (since the top image obscures the bottom one). Here's some info on multi image:
http://openseadragon.github.io/examples/multi-image/
The very easiest is to use sequence mode:
http://openseadragon.github.io/examples/tilesource-sequence/
But it's also very limited. Using the true multi image gives you more flexibility. Here's an example of fading between two images using multi image:
https://codepen.io/iangilman/pen/YXRLea

Thanks so much! I'll give this a spin!

Hi, just wanted to say this totally worked for me, so THANK YOU! Initial prototype looks like this:
http://www.snorkle.io/pathanalysis/?name1=https%3A//snorkle-output-files.s3.amazonaws.com//zoomimage_2_of_2_output/zoomimage_2_of_2_files/&width1=15636&height1=8467&name2=https%3A//snorkle-output-files.s3.amazonaws.com//zoomimage_1_of_2_output/zoomimage_1_of_2_files/&width2=15636&height2=8467

@neuro3d Awesome! Looking good :)


no_std support

It would be nice if we can add no_std support for at least the parts don't need rng. It's a good idea to define a rng trait and allow the user to pass it to the library.

Rand works fine without std. Floating point math however needs std, unless libm is used.

rand and nalgebra offer multiple features for this:

std
alloc
libm (only nalgebra)

AFAICT, std/alloc features are the norm across the ecosystem and it probably makes sense to adopt this too.
One disadvantage is that #[cfg] will appear more often and can increase mental load for contributors. Local testing will also become more difficult, but that's probably a price worth paying for good no_std support. Good documentation (for contributors and users) would also help.
Just some notes, I've played around with it and might go for a PR:

std effectively includes alloc and libm
feature std can depend on alloc but not libm (dependency mess)
every feature activates same feature in dependency "std" = ["nalgebra?/std", ...], default should include std
libm only really makes sense when in no_std (compile_error! via cfg prob. too much?)
Categorical, Empirical need alloc
Multivariates (Dirichlet, MVN, MVS, Multinomial)

require libm or std (float operations in nalgebra, e.g. Complex<f32>)
alloc or std add heap allocation (DVector, DMatrix, nalgebra::Dyn) support

some code can be rewritten to avoid allocations (avoid feature-gating stuff that doesn't 100% need it)
i don't think there's anything in the entire library that needs std. no_std + alloc + libm is probably good enough for everything? At least so far


can not load file "_ev_ops.so" on TF1.15.2

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
Darwin MacBookPro 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64
TensorFlow version and how it was installed (source or binary):
tf  1.15.2 install in conda by pip install
TensorFlow-Recommenders-Addons version and how it was installed (source or binary):
tfra   0.2.0 install in conda by pip install
Python version:
3.6.9
Is GPU used? (yes/no):
no
Describe the bug
when install tfra，tf will auto update to 2.4.1，but tf1.0 was used in my code, so I reinstall tf to 1.15.2
then I run demo with tfra.ev，error raise when tfra init

A clear and concise description of what the bug is.
Traceback (most recent call last):
File "/path/ev.py", line 5, in
import tensorflow_recommenders_addons as tfra
File "/path/py3/lib/python3.6/site-packages/tensorflow_recommenders_addons/init.py", line 31, in
from tensorflow_recommenders_addons import embedding_variable
File "/path/py3/lib/python3.6/site-packages/tensorflow_recommenders_addons/embedding_variable/init.py", line 1, in
from tensorflow_recommenders_addons.embedding_variable.python.ops.embedding_variable_ops import *
File "/path/py3/lib/python3.6/site-packages/tensorflow_recommenders_addons/embedding_variable/python/init.py", line 55, in
gen_ev_ops = _load_library("../core/_ev_ops.so")
File "/path/py3/lib/python3.6/site-packages/tensorflow_recommenders_addons/embedding_variable/python/init.py", line 52, in _load_library
"{}, from paths: {}\ncaused by: {}".format(filename, filenames, errs))
NotImplementedError: unable to open file: ../core/_ev_ops.so, from paths: ['/path/py3/lib/python3.6/site-packages/tensorflow_recommenders_addons/embedding_variable/python/../core/_ev_ops.so']
caused by: ['dlopen(/path/py3/lib/python3.6/site-packages/tensorflow_recommenders_addons/embedding_variable/python/../core/_ev_ops.so, 6): Library not loaded: @rpath/libtensorflow_framework.2.dylib\n  Referenced from: /path/py3/lib/python3.6/site-packages/tensorflow_recommenders_addons/embedding_variable/core/_ev_ops.so\n  Reason: image not found']
Code to reproduce the issue
import tensorflow_recommenders_addons as tfra
Provide a reproducible test case that is the bare minimum necessary to generate the problem.
Other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.

Hi @qqsun8819, any help?


No support for inequality requirements in python version dependency line

[x] I am on the latest Poetry version.
[x] I have searched the issues of this repo and believe that this is not a duplicate.
[ ] If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

OS version and name: MacOS
Poetry version: 0.12.2
Included below

[tool.poetry.dependencies]
python = ">=3.7"

Issue
The inequality requirements as documented here: https://poetry.eustace.io/docs/versions/#inequality-requirements should work for the python version too.
Right now installing something like urllib3 doesn't work:
Riley:testing xistence$ poetry add urllib3
Using version ^1.24 for urllib3

Updating dependencies
Resolving dependencies... (0.2s)

[SolverProblemError]
The current supported Python versions are >=3.7
Because no versions of urllib3 match >1.24,<2.0
 and urllib3 (1.24) requires Python >=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, <4, urllib3 is forbidden.
So, because test depends on urllib3 (^1.24), version solving failed.

add [-D|--dev] [--git GIT] [--path PATH] [-E|--extras EXTRAS] [--optional] [--python PYTHON] [--platform PLATFORM] [--allow-prereleases] [--dry-run] [--] <name> (<name>)...

This is the expected behavior, and is due to one of the changes in the resolver.
Basically you python constraint has no upper bound so it means it's also compatible with Python >= 4.0 while urllib3 is only compatible with Python <4 so the resolver cannot select it.
>>> from poetry.semver import parse_constraint
>>> parse_constraint(">=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, <4").allows_all(parse_constraint(">=3.7"))
False

To fix this you just have to change >=3.7 to ^3.7.

The rationale makes sense, just not something I was expecting. Thanks for the explanation!


⚠ Bofrost.gr has degraded performance

In 69f63c1, Bofrost.gr (https://www.bofrost.gr) experienced degraded performance:

HTTP code: 200
Response time: 1922 ms

Resolved: Bofrost.gr performance has improved in 3aed1cf.