Skip to content

Questions about making package public

Jump to bottom
William F. Broderick edited this page Mar 13, 2020 · 2 revisions

Our goal for this repo is to make a public python library, installable from PyPI (i.e., using pip), that contains a variety of synthesis algorithms and visual models, both for internal use and for the community.

Currently, the repo is private. The lab's standard way of doing things is to make code available once the associated project is published. This repo will contain code from many already-published projects, as well as from those currently under development, and so there are some questions we need to think about:

  1. Where do you want the repo to be when we make it public and put it on PyPI? What do you think the minimum viable product looks like? For example, "it should contain working implementations of metamer, eigendistortion, geodesic, and MAD competition, along with three simple models, and documentation, tests, and tutorials for all of them."

  2. We will need to publicize the project. Currently, my (Billy's) plan is to submit a poster to VSS and Cosyne (ideally, with associated projects so we can reference them), and to submit a paper to the Journal of Open Source Software, which we'll use as the main doi for people to cite. How does this sound? Is there anywhere else we should submit?

  3. Should we submit to conferences/journals at the same time as we make it public, or can we make it public first?

  4. When is the earliest and the latest you are comfortable making the repo public? E.g.:

    • by September / some other month
    • by the time the first project using the code is presented at a conference
    • by the time the first project using the code has a preprint
    • by the time the first project using the code is published in a journal

  5. What are your concerns about making the repo public? For example:

    • people will use it in good faith but have nothing to cite
    • people will use it in bad faith / try to scoop us
    • I don't want to have my work-in-progress available for anyone to see (because it's embarrassing / the code's not ready yet)
    • I don't want to have to support / maintain / stand by my work-in-progress (because it's unstable and I may change the code)

  6. Once this repo is public, one possible setup is to follow Gitflow. So, there will be a master branch that is stable, ready for users (people who aren't the developers) to use. Everything there will be fully documented, tested, and covered by the tutorials. This is the version that will live on PyPI and so be the easiest to install. Each new feature will live in a separate branch on the main repo and will be pulled into the develop branch when ready. We will periodically update the master branch from the develop branch, each time corresponding to a new release. This means all new features will be public, but will not be included in the main version of the repos that users will have, unless they go searching for it. Does this address any of your concerns from question 5?

  7. Some of the features that will be added to plentopic will start as research code, and so the developer (i.e., a student or postdoc in the lab) may not want it to be public right away. There's no way to selectively make branches private, but you could fork the repo, make your fork private, and then open a pull request when you're ready to merge it back into the main repo. You would lose access to the various nice automated helpers (readthedocs to automatically build and update the documentation, TravisCI to automatically run all the tests) and thus would be responsible for running the tests and building the documentation yourself to make sure everything looks okay before opening the pull request. Depending on your settings, it may also make collaboration more difficult. But you will have a private repo that maintains its connections to the master version. Does this address any of your concerns from question 5?

Please add more questions!

Post-discussion notes

We discussed the above on March 13, 2020 and came to the following conclusions:

  1. Minimum viable product?
    • the stuff that's been published so far: geodesics, mad competition, metamer, and eigendistortion. plus some simple models
    • but what models? focus on stuff that's published
    • there's models in there right now, so clean them up, and make sure to show how torchvision / deep net models can work with this framework
    • models focused on explaining physiological variance more ambitious, reimplementing older stuff from lab should be done but could make good rotation project -- should probably be a separate repo, focusing on models
    • V1 model: do we need anything beyond the steerable pyramid and my VentralStream model? could just take steerable pyramid, maybe add rectifier, and pooling.
    • make sure non-down-sampled version of the spectral steerable pyramid works
    • Portilla-Simoncelli texture statistics
    • see Roadmap for what we have to do on this
  2. For publicizing:
    • might be useful to try and get a whole workshop or hackathon so people can get their hands on it
    • e.g., Cosyne workshop that focuses on synthesis, with one of us running it. then could focus on it
    • for getting into conferences, probably easier to get in with a novel project that uses it, rather than the package itself
    • maybe aim for one or two VSSes from now, could try and have a satellite event tutorial for this
    • talk with Noah Benson about how he's tried to get people to use his neuropythy / HCP retinotopy / Standard Cortical Observer model
    • could do like what John Cunningham did this year and have Eero give some sort of talk to convince people to use it
    • JOSS sounds good for publication and doi
  3. Everyone agreed with the stuff discussed in section 1 above, all the published things, being public. But how do we handle projects moving forward? There are three options for people's ongoing research, and they can choose:
    • if you're fine with your work being public, you can just make it a branch in the repo. it won't be included in the package on pypi until pulled into the master branch, so no worry about people trying to use something in-progress (but it exists on the internet and can be found by the general public).
    • if you don't want your work to be public until it's ready, but it's within the scope of plenoptic (and you'd like to include it), you can make a private fork of the project. you'll lose the various automations, and so need to check the tests and documentation builds yourself, but you'll be able to open a PR and merge back without a problem
    • if your work it outside the scope of plenoptic, you can make a separate repo (private or public, up to you), which uses plenoptic as a dependency. this is easiest if you're only using stuff currently included in the package on pip, but can still work if you're using one of the development branches as well.
Clone this wiki locally