Conda-forge.github.io: Removal of half of bob packages.

[183amir]

Hi everyone,

I have submitted 65 bob packages here while the core bob is only around 31 packages.
The rest of packages are purely python packages and can be easily installed with pip.

I was wondering if it is possible to remove half of these python only feedstocks from conda-forge?
I can put a list of feedstocks here.

[183amir]

It would also less clog the CIs when we release a new bob each month.

[183amir]

Here is a list of them:

bob.db.verification.utils
bob.db.verification.filelist
antispoofing.utils
bob.db.arface
bob.db.banca
bob.db.biosecure
bob.db.caspeal
bob.db.frgc
bob.db.gbu
bob.db.lfw
bob.db.mobio
bob.db.multipie
bob.db.scface
bob.db.xm2vts
bob.db.youtube
bob.db.nist_sre12
bob.db.utfvp
bob.db.livdet2013
bob.db.atvskeystroke
bob.db.kboc16
bob.db.biosecurid.face
bob.db.casme2
bob.db.replay
bob.db.msu_mfsd_mod
bob.db.avspoof
bob.db.voxforge
bob.db.casia_fasd
bob.bio.base
bob.bio.gmm
bob.bio.spear
bob.bio.face
bob.bio.video

ping @conda-forge/core

[patricksnape]

I don't know what our procedure is for this. I think this might be best approached via a CFEP 😄

[ocefpaf]

I don't know what our procedure is for this. I think this might be best approached via a CFEP 😄

@patricksnape not really. @183amir is the main maintainer of those packages and they all belong to a single "ecosystem" that is the bob.<packages>. I would not bother removing them though. If the reason is the burden of maintaining them, I would just leave them be (no more updates). But if @183amir wants them removed we can do that for him.

[ChrisBarker-NOAA]

On Tue, Sep 27, 2016 at 5:00 AM, Amir Mohammadi [email protected]
wrote:

I have submitted 65 bob packages here while the core bob is only around
31 packages.

The rest of packages are purely python packages and can be easily
installed with pip.

I was wondering if it is possible to remove half of these python only
feedstocks from conda-forge?

Personally, I think it's best if folks can get everything from conda, and
not have a pip-conda mix confusion.

Could you do a (or a couple) mega-package that contained a bunch of bob
sub-packages?

There is no reason that a conda package has to hold only one python package.

-CHB

[patricksnape]

@ocefpaf But then we could have uploaded packages that don't match with staged-recipes which feels dirty. And if we have to go manually into anaconda.org and start removing packages that feels like it should be well defined how and when that happens?

I also agree with @ChrisBarker-NOAA and @ocefpaf - why not just leave these on conda?

[ChrisBarker-NOAA]

Another note:

If, in the future, you want your users to get a particular package from pip/pypi, rather than conda-forge, it's probably better to remove the old versions from anaconda.org. People will get really confused otherwise.

[183amir]

Well adding those packages in the first place was a mistake I think. We have/had a clear policy of distributing only core bob packages in binary in an environment.
Now that I don't want to maintain those extra ones anymore, I also want them removed from here.

This would:

• prevent people from installing old versions from conda
• prevent re-rendering pulls that I receive on the feedstocks.
• undo my first mistake :)

[ocefpaf]

Well adding those packages in the first place was a mistake I think.

I disagree but that is not the issue here. Conda-forge has tons of pure-python packages and there are many good reason to keep packaging them.

We have/had a clear policy of distributing only core bob packages in binary in an environment.

If by _we_ you mean conda-forge. No. If you mean your working group, that is a fine strategy and I fully understand that. Specially in the light of the new conda-env+pip workflow.

Now that I don't want to maintain those extra ones anymore, I also want them removed from here.

That is, IMO, a no brainier. Like I said above, even though I would not remove any packages, I can see why you want them removed.

prevent people from installing old versions from conda

That, for one, is a nice reason. But abandoned packages are bound to happen (we already have many btw) and it is not such a big issue.

prevent re-rendering pulls that I receive on the feedstocks.

If you can remove yourself as the maintainer if that is the main reason BTW. But since you are the sole maintainer and your work group is the number one users of those packages I see why removing makes more sense.

@ocefpaf But then we could have uploaded packages that don't match with staged-recipes which feels dirty.

That already happened and will happen again. We do not need to have a one-to-one correspondence with staged-recipes at all. (The very first feedstocks we created were before staged-recipes even existed!) And I don't think that is in any way dirty.

And if we have to go manually into anaconda.org and start removing packages that feels like it should be well defined how and when that happens?

Indeed. But I don't think we need CFEP for that. Even more for @183amir bob packages.

@183amir if you can get a few more @conda-forge/core to give you the :+1: I can take care of the removal for you.

[ChrisBarker-NOAA]

I don't know if I'm core, but 👍 from me.

If they are no longer going to be maintained in conda-forge, it is better to remove them.

-CHB

[mwcraig]

I'm not entirely sure that "what does pypi do" should be a guiding principle here, but pypi certainly allows package authors to delete uploads and, I think, delete packages. Count me as 👍

It might be nice if anaconda server also prevented re-uploading a package with the same exact name/version (pypi does that, and conda build number increments are the way to handle issues with incorrectly built packages). That decision is out-of-scope for conda-forge, though.

[patricksnape]

I won't stand in the way - 👍 from me.

[183amir]

Thank you everyone.

[ocefpaf]

@183amir can you check if you are able to remove the feedstock. If not I will do that for you.

I believe I already for all the packages in anaconda.org please let me know if I missed any.

[183amir]

@183amir can you check if you are able to remove the feedstock. If not I will do that for you.

unfortunately, I cannot.

[pelson]

For the sake of reproducibility (of recipes), I wonder if we need to introduce the concept of a dormant feedstock. Provided it was labelled appropriately, we could easily avoid MNT PRs to it, and so there would be very little cost to it continuing to live in conda-forge (even without any maintainers).

[183amir]

@ocefpaf you have missed this: https://github.com/conda-forge/bob.db.frgc-feedstock

[jakirkham]

I really like the idea of dormant recipes and can already think of a few use cases.

[ocefpaf]

For the sake of reproducibility (of recipes), I wonder if we need to introduce the concept of a dormant feedstock.

Not sure if we need anything special. I would never delete a feedstock BTW. I'd just unsubscribe/remove myself as maintainer and let it be.

[ChrisBarker-NOAA]

On Fri, Sep 30, 2016 at 6:29 AM, Filipe [email protected] wrote:

For the sake of reproducibility (of recipes), I wonder if we need to
introduce the concept of a dormant feedstock.

Not sure if we need anything special. I would never delete a feedstock
BTW. I'd just unsubscribe/remove myself as maintainer and let it be.

good point -- if no one changes, it, then it'll never get re-built.

But it might be nice to have it flagged somehow, so others that find it
will know it's not being maintained.

Maybe just a note at the top of the README?

-CHB

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/conda-forge/conda-forge.github.io/issues/243#issuecomment-250744566,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA38YCJdB8aQKja-AsYUjDN9ROj0Wn79ks5qvQ7VgaJpZM4KHlL3
.

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R [phone] voice
7600 Sand Point Way NE [phone] fax
Seattle, WA 98115 [phone] main reception

Chris.[email protected]

[jakirkham]

So there is a cost to generating re-rendering PRs, pinning PRs, any other automated PR yet to be created, also there is a cost for CI jobs started by all those things, further there are various global update checks (teams, feedstocks repo, webpage, etc.). Actually being able to switch all that stuff off on unmaintained feedstocks is good for the feedstocks that are being maintained. So even if we don't listen to these events, there is a price for their occurrence.

All in favor for adding a note to the README, removing it from the webpage repo, and whatever else along these lines.

Don't think we need an additional flag. What about an empty maintainers' list? This gets the point across and can be combined with a re-rendering to turn most local things off.

Global scripts will have to track this state somehow.

[jakirkham]

FWIW I deleted all the bob teams without an associated feedstock. That was based off this list and subsequently re-ran the team update script. This would have re-added any missing feedstock teams. So think we are all set.

[183amir]

Thank you everyone for your efforts and understanding.