Description

If I do a search with more than one term from a plugin details page, the space(s) are not serialized properly, returning no results.

Steps/Code to Reproduce

1. start from any details page
2. at the top bar, search for "cell counting"

Expected Results

Actual Results

Note URL has the search term as cell%2520counting when it should be cell%20counting. It appears to be getting serialized for the URL twice

see #15 (comment)

from June 2020 pre-launch bug bash

Created by: Kira Evans

Description

how to reproduce (on iPad):

1. load https://staging.napari-hub.org/plugins/napari-btrack-reader or any other plugin page
2. click "Installation" to navigate to that header (link should be https://staging.napari-hub.org/plugins/napari-btrack-reader#installation)
3. click subscribe on the signup form with an invalid email
4. your page will scroll back to the Installation header

this does not occur with valid emails and I cannot reproduce on Desktop

Info

Bug source: unknown

Browser: Safari, Firefox, Edge, Chrome

PR: none

Attachments

Description

Rendering the description for napari-properties-viewer appears to be broken.

• right nav doesn't work
• missing image
• "image" in h2

Steps/Code to Reproduce

visit https://www.napari-hub.org/plugins/napari-properties-viewer

Expected Results

A cleanly rendered description :D

Actual Results

It seems like the markdown parser might be mis-interpreting what is intended to be a horizontal line as designating the image (which can't render b/c it is referenced as a relative link) as a heading?

Markdown here: https://raw.githubusercontent.com/kevinyamauchi/napari-properties-viewer/main/README.md

For our initial launch of the napari hub, we have identified some of the key pieces of data re: napari plugins that we want to pull in from PyPI and Github to help users find the right plugin for their needs.

This metadata will be used for the following.

• shown on the plugin detail page
• previewed on plugin search listings
• available for filtering on plugin search listings
• available for sorting on plugin search listings
• indexed for searching

For much of this data, the source is clear, but for some data there are either (a) have multiple possible sources, (b) no clear source, or (c) do not have a source.

• Description: PyPI description may not be relevant to plugin users
• Author: Multiple places to define authorship
• License: There are multiple possible sources of license info in PyPI & Github
• Python version: There are two places to pull this info
• Operating System: There are multiple places to infer this

(for a full breakdown of what metadata will be shown/used where, see Metadata Fields for v0)

from June 2020 pre-launch bug bash

Created by: Lia

Description

Sorry if this was not clear in the design, but the spacing should start at 15px (at our smallest supported screen size: 300px)

Info

Bug source: 300px - 495px

Browser: unknown

PR: none

Attachments

https://dl.airtable.com/.attachments/7fb37fbe8b86de377f4fd8fbc05f1411/570748e0/ScreenShot2021-06-16at3_06_30PM.png

Nearly all napari plugins have a PyPI description sourced from their Github README, however we would like to let plugin developers provide a description of their plugin tailored to napari hub users.

This is especially important for plugins that are offered as general purpose Python packages... These will likely will want to have distinct intros, descriptions, and usage guidance for different platforms and audiences so as not to confuse users.

The proposed source of this napari-specific description would be a markdown file in the plugin developer's code repository.

For example...

• NAPARI.md in the top level of the repo

There is other metadata that we'd like to let plugin developers control independently of fields in PyPI as well, including author information and (eventually) tags or categories.

In this case, it might be better to define a hidden folder for napari config info (.napari/) then put the description in there, along with any other config files...

• .napari/DESCRIPTION.md
• .napari/README.md

Thoughts?

from June 2020 pre-launch bug bash

Created by: Kira Evans

Description

on iPad landscape and portrait the center dot in the radio button is off-center

Info

Bug source: 1366px x 908px

Browser: Chrome, Safari, Firefox, Edge

PR: none

Attachments

https://dl.airtable.com/.attachments/205430c13a358030ee8675caed96d923/748ae21c/713B95E8-133E-4ABC-9180-CF1DB9FFFA04.png

some people might be curious to know when they can expect to see some upstream change reflected on the hub. For example, how frequently is PyPI scraped, and if someone makes a change to their github .napari metadata, when is that detected...

Might be a nice item to add to the FAQ.

from June 2020 pre-launch bug bash

Created by: Lia

Description

Since the breakpoints that exist exclusively for the home page are based on the width that things are rendered, they need a little refining since the rendering of some elements in HTML is not exactly the same as the design (i.e. spacing between bullet disc and bullet text, etc). This is fine, but slightly affects the point at which the breakpoint itself should occur.

Work with Lia to refine. Dependent on #66 being completed first

Info

Bug source: <875px

Browser: unknown

PR: none

Attachments

https://dl.airtable.com/.attachments/e9db5ba7de6fd2a90f43b1d42583e77e/29a11dd5/ScreenShot2021-06-16at3.31.43PM.png

There are a number of metadata fields that we want to support in our first release and beyond that either aren't available in PyPI or that we want to let plugin developers customize while maintaining separate fields in PyPI (authors, description].

To support customization of these fields, we would like to let plugin devs put a napari-specific config file in their plugin repo, similar to the config files used for CI/CD tooling (.flake8, .travis.yml, .readthedocs.yml)

This brings about two questions:

1. What format should we use? YAML? TOML?
2. Where should this metadata be defined? .napari.yml? .napari/CONFIG.yml? setup.cfg?

from June 2020 pre-launch bug bash

Created by: Allen

Description

License filter options for the common licenses people want to exclusively use (e.g. GNU General Public License)

Info

Bug source: unknown

Browser: unknown

PR: none

Attachments

There are multiple available sources for this metadata:

Trove Classifiers

PyPI lets package developers tag their package with the operating system that it supports through trove classifiers, but its not clear how widely this is used. The napari plugin cookie-cutter sets this to 'Operating System :: OS Independent'.

Inspect the name of the wheel

If the plugin developer has built wheels that are specific to a certain OS, then this information is encoded in the filename of the wheel: "any" for OS-agnostic builds vs "win_amd64" for a 64-bit windows build, for example (see https://realpython.com/python-wheels/#building-a-platform-wheel-macos-and-windows)

Primary persona(s)

• Research Biologist
• Imaging Scientist
• Bioimage Analyst

Job Stories

• When I browse for plugins I want to know only the dependencies specifically required for installation so that I know the minimum requirements / conflicts with my current environment.

Acceptance Criteria

1. [If I do A, B should happen.]

If I browse napari plugins, only required dependencies should be shown:

(Nothing with "extra" should be shown, OR it should be separated into an accordian view?)
(source: aicsimageio napari-hub page)

Don't know anything about how the search is implemented here... but instant search (ala algolia) might be a nice feature for the search field. Doesn't seem like we should have too much data for that sort of thing for quite a while?

from June 2020 pre-launch bug bash

Created by: Kira Evans

Description

the gray circle indicating that you are hovering over the checkbox is misaligned with the checkbox itself

Info

Bug source: unknown

Browser: unknown

PR: none

Attachments

https://dl.airtable.com/.attachments/91dd4290861df3f59fd817afff8085a0/e01303e7/ScreenShot2021-06-29at9.02.56PM.png

It would be great if hub provides and API napari could query to get information on plugins without having to query pypi directly.

This would allow to display information in the plugin/package manager inside napari that matches the look feel and information of napari hub.

can we add "PartSeg" to the exclusion list? even though it has the "Framework :: napari" trove classifier, it isn't a napari plugin

in the future, we should consider automatically excluding packages that have the trove classifier but don't have hook implementations, but until then, we can manually clean up the listings for users.

cc @Czaki

from June 2020 pre-launch bug bash

fOnce search is clicked at, the "zoom glass" icon appears bordered.

Description

in the modal dialog that pops up when you click an "install" button, the text says "... paste it where it says “Install by name/url…”, but the image shown is from before napari had the "install by name" option. That might be a bit confusing?

add napping to the exclusion list... napping is an application built on top of python and won't install through the plugin installer.

from June 2020 pre-launch bug bash

Created by: unknown

Description

No description

Info

Bug source: unknown

Browser: unknown

PR: none

Attachments

Privacy Notice has link to plausible.io/napari.dev instead of plausible.io/napari-hub.org

Description

I was surprised that "Removing" a plugin from napari uninstalled it from my environment.

Steps/Code to Reproduce

• Start napari
• open "Plugins" > "Install/Uninstall Packages"
• find ome-zarr under "Installed Plugins"
• click on "remove"

Expected Results

I perhaps naively assumed this would just remove the plugin from the current context.

Actual Results

The package was uninstalled.

There are multiple sources to pull author info from:

Author field in pypi

PyPI requires an author field & email, but it only supports one author. Further, it is often a group-level author, not an individual.

Let plugin dev define authors in custom

We could enable plugin devs to explicitly list the Authors of the plugin through a custom metadata file in the repo (e.g. .napari.yml). This would have the benefit of letting plugin devs explicitly list and order the authors of the plugin (including PIs or other non-code contributors).

Show list of contributors from the git history

We could also get the full list of contributors to the repository and present this info... however, this would only include code contributions and could get unwieldy for plugins with large efforts behind them.

from June 2020 pre-launch bug bash

Created by: unknown

Description

"Documentation" seems to be to the left compared to other text

Info

Bug source: unknown

Browser: unknown

PR: none

Attachments

https://dl.airtable.com/.attachments/f3ae7e533d67c6c5e8e228a4c2a0aea6/e23fe4c6/ScreenShot2021-06-23at11.41.26AM.png

from June 2020 pre-launch bug bash

Created by: Kira Evans

Description

steps to reproduce (on iPad):

1. apply a filter
2. clear the filter by clicking on the X on the tag chip

Info

Bug source: unknown

Browser: Firefox, Safari, Edge, Chrome

PR: none

Attachments

https://dl.airtable.com/.attachments/5b1c1f58a54c165c107c2125ee9b06b8/b52837a4/2750B669-64FF-4296-A716-949AAF45797A.png https://dl.airtable.com/.attachments/27f16db378a761d6afb62394db0668e8/6f1d0453/B1AF92AA-4073-4351-AC77-FC3C7265A1C3.png

the about page of napari hub doesn't directly link to napari github or home page. There's a link to the governance model, a link to czi imaging, and a link to this repository... but the only actual link to napari seems to be the icon on the bottom right. Perhaps the first "napari" word could be a link to napari

For SEO purposes, we should make sure that the site only renders at either www.napari-hub.org or napari-hub.org, but not both.

My understanding is that www.napari-hub.org is preferable, as it will better future-proof us if we start to need other subdomains (e.g. api.napari-hub.org for #133)

Whichever we choose, we should ensure that the other has a permanent redirect (e.g. redirect napari-hub.org to www.napari-hub.org)

from June 2020 pre-launch bug bash

Created by: Allen

Description

Does anyone care about "First released?" Why?

Info

Bug source: unknown

Browser: unknown

PR: none

Attachments

from June 2020 pre-launch bug bash

Created by: Lia

Description

Should be 50px tall, inspector says it is 60px tall; should be semi-bold, inspector says it is normal

Info

Bug source: unknown

Browser: Safari

PR: none

Attachments

from June 2020 pre-launch bug bash

Created by: Lia

Description

Currently regular weight; applies to Install button at top / right margin and at bottom

Info

Bug source: All

Browser: Chrome + Safari

PR: none

Attachments

from June 2020 pre-launch bug bash

Created by: Lia

Description

A little too tall
Not right color grey (too dark)
Not enough space between end of “x” and end of chip

Info

Bug source: All

Browser: Chrome

PR: none

Attachments

To identify the license of a napari plugin, there are multiple possible sources of this metadata:

• “License” in PyPI JSON (free text set in setup.py)
• “License” Classifier in PyPI JSON (controlled vocabulary set in classifiers)
• Github API for the repository

Note: The current behavior of the napari plugin cookiecutter is to give the user 6 choices, then set ALL of the above fields.

Which field should the napari hub rely on to identify the license for a plugin? If we pick one as primary/preferred, should one or more of the others be a fallback?

from June 2020 pre-launch bug bash

Created by: Lia

Description

The vertical spacing between the radio buttons + their labels is to tall compared to design

Info

Bug source: on wider than mobile sizes

Browser: Chrome

PR: none

Attachments

There are two available sources

“Python_requires” in PyPi (looks like “>=3.7”)

• This is what pip relies on to decide whether a plugin can be installed, so we can be fairly confident that plugin devs are keeping it up to date
• Would we want to parse it to provide an explicit list of versions? E.g. “>=3.8” would become “3.8, 3.9” and filtering on 3.7 would exclude this plugin?

Trove classifier in PyPI (looks like “Programming Language :: Python :: 3.7” etc)

• This is what shields.io looks for (see https://shields.io/category/platform-support)
• When a new version of Python is released, plugin devs would need to manually tag their plugin by adding another trove classifier

I'm very excited about the upcoming hub release and want to thank you for your efforts!

I'd would, though, like to open a discussion and share some thoughts/concerns on some of the "sales-pitchy/marketing" language that I see used on services like the hub and napari.dev. First: I think these are both awesome services: I'm super appreciative and I can't wait to see them get off the ground. I do, however, sometimes find myself feeling uncomfortable as I read them. Some of the wording comes off sounding like an advertisement, and feels a bit out of place in a scientific environment. I do recognize that there is generally language somewhere else on the page that clarifies that "some of this is aspirational", as opposed to "this is already concretely available". But that approach can feel like a bit of a trick... as though it's left as an exercise to the perceptive reader to realize that you can't really do these things yet. (I'd kind of prefer that we underpromise/overdeliver... rather than be seen as a community that likes to wrap things in an overly sunny package)

Some examples from the hub

• "plugin users can ... be confident they've found the right plugin for their data and "it just works"

that feels extremely hard to do ... and i'm not immediately sure how we can promise that? if it's anything like most scientific communities, i suspect it will be more like a typical "try some of the more popular plugins until you hit on something that eventually works for you". no?

• "plugin builders can capture reliable actionable feedback...

I mean, I hope that's the case. but since the feedback is coming from the community, how can we promise that the feedback is either reliable or actionable?

• "Install into napari with confidence"

feels like marketing talk for "we'll remind you how install plugins" ... but whether they install correctly is out of our hands...

and from napari.dev ...

• big bold type at the top: "Share your analysis tool with researchers everywhere — No GUI development required."... "napari is designed with researchers’ needs in mind and takes the GUI work off your hands."

there too, that's an aspiration that we have, but have definitely not achieved... but that's not really clear anywhere on that page at all. it also makes it sound like napari was designed by some organization that may or may not actually be researchers, but with them as a target market... which is definitely not the case. This one particularly feels like it needs to be wrapped in a "we hope to someday" sort of preamble

• "Commit your changes. We’ll handle the testing."

again... that would be amazing... but as we all know... that's proven to be quite challenging, and it reads like we've already achieved it.

Anyway, just want to re-emphasize that I recognize these things are meant to be aspirational, and not necessarily taken literally... but as a core developer on the program being referenced they make me feel a little uncomfortable. While it probably does work to build excitement, it doesn't quite feel "authentic". I find myself wondering why it needs to be stated as such.

Hope you don't mind me saying so, and thanks again for the awesome, exciting resource.

from June 2020 pre-launch bug bash

Created by: justin

Description

I expected the filters to be in order.... 3.7, 3.8, 3.9

Info

Bug source: wide

Browser: chrome

PR: #86

Attachments

https://dl.airtable.com/.attachments/0921d80bc1ddfbe2882bb28c843c6b63/85b2ecc9/image.png

Is your feature request related to a problem? Please describe.
I'm developing a few plugins, and often new ideas take over, but old plugins remain on PyPI. I'd like to ensure that those stale plugins are not visible on the napari hub, potentially confusing users (e.g. should they use napari-cellfinder or cellfinder-napari?)

Describe the solution you'd like
Some way of easy marking the repository as not for the napari hub, e.g. .napari/.hub-ignore

Describe alternatives you've considered
I could remove them from PyPI, but I'd like to keep them there to support existing projects.

With the definition of metadata being laid out here: https://github.com/chanzuckerberg/napari-hub/blob/main/docs/customizing-plugin-listing.md, there are references sourced from GitHub, this becomes an issue across multiple versions, since the GitHub tag may not necessarily correspond to the PyPI release number, for example, a v0.0.1 release may be tagged as 0.0.1 in GitHub, I wonder what people think about managing metadata from github in regards to versions?

from June 2020 pre-launch bug bash

Created by: justin

Description

when I click the next-to-last item on the right nav, if the last two sections are short, the last item gets highlighted. this happens on the about page as well as plugin pages

Info

Bug source: wide

Browser: chrome

PR: none

Attachments

https://dl.airtable.com/.attachments/f1adb5121031e79c3bdb51bfc8e8d8b7/c9fe1aa4/image.png

requested by the author, @JoOkuma:

You can manually exclude it from the Napari hub and once it is more mature I can get in touch to make it available.

from June 2020 pre-launch bug bash

Created by: Jeremy

Description

One tiny thing I am adding now, but can be done for bug bash (or later, if not triaged for bug bash time):The vertical spacing between the radio buttons + their labels (on wider than mobile sizes) is a little too tall.

Info

Bug source: >875

Browser: All Browsers

PR: none

Attachments

https://dl.airtable.com/.attachments/f4afb407ff0428cc149d7c87e90fff82/fbca0571/image.png

from June 2020 pre-launch bug bash

Created by: Allen

Description

When searching for the empty string, "", the search parameter is not added to the URL. I consider this a design issue rather than a functionality issue.

Info

Bug source: unknown

Browser: unknown

PR: none

Attachments

I forget if has been discussed somewhere, but it looks like RST readme's aren't currently supported on the hub:

https://staging.napari-hub.org/plugins/napari-dv

The metadata for that repo doesn't specify a long_description_format ... which, for PyPI, implies RST, and indeed it renders fine there: https://pypi.org/project/napari-dv/

is that something we can support?