I am looking for a Rust library to parse dates and I found the documentation for time which looks official.
I wanted to report a bug so I went to the Crates.io page, which led me to the Github repository which sneakily redirected to the rust-deprecated Github account.
Is this library deprecated or not? How can I find out? There's no indication in the documentation or the code.
One problem here is that libraries often become deprecated because the maintainer doesn't have time. So the person who has the power to say "deprecated" also isn't in the position to do it.
The next release of Rust (1.9) will contain a "deprecated" attribute, which would allow someone to mark any part of an API as deprecated, and I guess it could be applied to a whole crate too.
That said, for "time", "deprecated" has a very specific meaning: it's a crate that was almost official, but is not any more, and has not had a new maintainer yet. If anyone wants to take over maintenance, they can request it, and it will be given to them. This only applies to crates that are in the rust-lang-nursery organization, and even that is a bit of history. In the future, I doubt many crates will end up "deprecated" in this way.
Related
I have accidentally published my private crate to crates.io. How do I delete it? I checked the documentation but it seems like there is no way to delete a published crate.
Prevention
To avoid this situation in the future, ensure that you include:
[package]
# ...
publish = false
in your crate's Cargo.toml. See documentation.
Mitigation
Immediately yank the crate using:
cargo yank --vers <your-version>
This will prevent any other crate to accidentally start depending on it.
If any secret was accidentally published (passwords, keys, ...), consider them no longer secret and take appropriate steps to replace them with fresh ones.
Removal
Contact help at crates.io and explain the situation, asking for removal.
If your explanation is well-founded, and the crate has not been downloaded and thus depended on, they have no reason to refuse helping.
Please be patient; once the crate is yanked nobody can start depending on it anyway, so there should be little time pressure. Give the team a few days to actually perform the removal.
If the matter is time sensitive for some reason, you can hop on IRC or Discourse and grab the attention of someone with the powers to perform the removal. Ask and you'll be directed to such a person.
The Crates.io policies say this under Removal:
We will do what the law requires us to do, and address flagrant violations of the Rust Code of Conduct. […] Crates.io will respect Mozilla Legal’s decisions with regards to content that is hosted.
I suggest to send mail to help#crates.io as a start, and if they prove uncooperative, escalate to Mozilla Legal. Only as a last resort, add a deliberate Code of Conduct violation to trigger the removal.
EDIT I agree that this is not a desirable situation, so I submitted a pull request with a proposed policy change.
You cannot delete a crate once it is published. However, you can yank it to mark your crate as not usable: basically, nobody will use it, and no or few people will want to see the content. This policy allows to forbid the arbitrary breakage of other crates that use your package as a dependency.
If you have code or information in this crate that you do not want to be public, refer to the other answer.
I don't know the best way to solve a simple (probably) problems (hackage related).
I asked for help about it (http://stackoverflow.com/questions/12841599/haskell-hackage-ghc-and-productivity-what-to-do) but I knew not explain well.
Today, I'm with a this kin problem.
The concrete problem isn't relevant, but is it:
`Write a function that, given a string, remove diacritics.`
Example:
`simpleWord "Cigüeñal" <-> "Ciguenal"
The correct way (I think) is to use the standard Unicode normalization. In some languages/frameworks (.Net, PHP, Python, ...) exist some related function.
In Haskell, thanks to hackage community exist too:
`Text.Unicode.Normalization.normalize`
But, I couldn't install with (eg) ghc-7.4 but compact-string (that depends of) fail.
A fix for compact-string exists (compact-string-fix) then: can't I use cabal to install (directly)?, should I download and patch it?, should I look for another alternative to function about?
I explained a concrete real case (simple or complex, don't care), the question (that I ask help for) is how can, a novice haskeller, know the best way to select correct libraries, ghc correct (balanced) version, without hit a wall.
I'm really lost about it.
Really, thank you very much for any suggestion.
Best regards.
The documentation for compact-string says, "This package is obsolete. Use text instead.".
The documentation for text says, "To use an extended and very rich family of functions for working with Unicode text (including normalization, regular expressions, non-standard encodings, text breaking, and locales), see the text-icu package.".
The documentation for text-icu shows that it successfully builds on GHC 7.4 and has support for Unicode normalization.
Here's the general process I follow when deciding which packages to use. First, I try to identify multiple packages that meet my needs. Then I look more closely at each package to try to determine which ones are the best for me, according to the criteria listed below.
It's usually better to use packages that are currently maintained. To determine if a package is currently maintained, I check the "Upload date" link on the package description page. (Of course, there are some old tried-and-true packages that haven't been modified in ages because they don't need modification.)
It's usually better to use packages that are mature, so I check the version number on the package description page. A package with a version number of 7.3.5 is probably more mature than a version 0.1 package.
It's usually better to use packages that are well documented. Sometimes there's a nice example of how to use the package in the Haddock documentation (yay!). I'll also check the "Home page" link on the package description page, because often there will be more documentation there.
It's usually better to use packages that are popular, because any problems will probably be addressed quickly, and other users can answer questions. I'll usually do a Google search and see whch packages are mentioned most often on Haskell mailing lists and StackOverflow.
It's usually better to use packages that don't require a lot of packages I don't already have, so I check the "Dependencies" section on the package description page.
I tend to follow this procedure when choosing a package for any programming language, not just Haskell.
I have a package on Hackage which depends on third-party package, which doesn't build on newer versions of GHC (>= 7.2). The problem with the other package can be solved with just a one-line patch (a LANGUAGE pragma). I sent the patch to the upstream twice, but didn't receive any feedback. The problem is that my package is not installable neither until the dependency is fixed.
I could have uploaded the fixed version of depenency package (with a minor version bump), but I'd like to hear what is the attitude of the community about such non-maintainer uploads. Again, I don't want to change the library interface, I only add a new compilation flag to make it buildable again.
Are non-maintainer uploads to Hackage allowed and tolerated?
When a fork of the package on Hackage is a better approach?
Package uploads by non-maintainers are allowed (there may be license issues, but most packages if not all on hackage have licenses permitting this), but of course they are not usually done. They are tolerated if done in good faith and with reasonable procedure. If you contact the maintainer and don't get any response within n weeks (where I'm not sure what the appropriate value of n is, not less than 3, I'd say), uploading a new version yourself becomes an option, discussing that on the mailing lists seems however more prudent. If the package looks like it is abandoned, even taking over maintainership - of course after again contacting the maintainer, giving her/him time to respond - may be the appropriate action, but that should definitely be discussed with the community (haskell-cafe or mailing list, for example). Whether to prefer a non-maintainer upload or a fork must be left to your judgment, personally I tend to believe forks step on fewer people's toes.
But a better founded reply would be possible if we knew which package is concerned and could look at the concrete situation.
A forking is intrusive for a package that you suspect is still maintained but the author is temporarily missing. By intrusive, I mean that other programmers might pick up your fork then not go back to the mainline once the original author has resumed work on the mainline.
For packages where the original author has left the Haskell community, my personal opinion is that its better to fork the package if you are going to develop it further. Forking prevents succession problems, such as those that happened with Parsec where many developers didn't want to update because the successor was slower and less well documented than the original for some time.
In all cases asking on the Cafe is best, regardless of whether people have chosen not to follow it, it is still the center of the Haskell community.
For the particular case in the question, while it is nice if things on Hackage compile, there is no rule that says they have to. A package that depends on a broken package could simply put change instructions for the broken dependency on its front page, i.e. "This package depends on LambdaThing-0.2.0 which is broken, to fix LambdaThing add ... to the file Lambda.hs"
I would say, it's a very good idea to consult the mailing lists regarding the specific package and the specific person who is missing. I took control of the haskell-src-meta package from its original owner, but only after consulting with the lists and IRC, who assured me that Matt Morrow had been missing for months and no-one knew why.
In my opinion, package ownership should probably only be changed where there is a consensus to do so, or at the very least there should be efforts made to find one. In the development version of the Hackage software, it's my understanding there are access controls so that only administrators can make this kind of intervention.
Cabal allows for a freeform Stability field:
stability: freeform
The stability level of the package, e.g. alpha, experimental, provisional, stable.
What are the community conventions about these stability values? What is considered experimental and what is provisional? I see only few packages are declared as stable. What kind of stability does it refer to, stability of the exposed API or the ultimate bug-free state of the software?
The field is mostly defunct now, and shouldn't be used. As Max said, it will probably be replaced by something meaningful in the future.
If you're interested in the history, the field originated in a design proposal for the first set of Hierarchical Haskell Libraries. That document describes the original intended meanings for the values.
Currently this field is a very poor guide to the stability of the library, so is mostly ignored. Duncan Coutts (one of the main Cabal and Hackage developers) has said that he eventually plans to replace this field entirely, with something like a social voting system on Hackage.
Personally (and I'm not alone) I just always omit the stability field. Given that it's going to go away, its probably not worth losing any sleep over what to put into it.
The original intended meanings were:
experimental: the API is unstable. It may change at any time, i.e.: any version number change;
provisional: the API is moving towards stability. It may be changed at every minor revision, but should provide deprecated versions of features;
stable: the API is stable. Only additions should be made at minor releases. After changes in the API, deprecated features should be kept for at least one major release.
As the other answers pointed out, the community seems not to be following these guidelines anymore.
As Simon Marlow points out, this is described in a design proposal for the first set of Hierarchical Haskell Libraries. The original link is dead, but you can find a copy in the wayback machine.
No tool is perfect, and I'm about to start several long-term projects using Trac, and wanted a heads up of the kinds of problems I may or may not experience with it. In other words, Trac meets my needs in the short term, and I've already made the decision to use it, but I want to know what to expect down the road.
I am not looking for:
"Use product X instead of Trac because..." answers.
"Trac is great because..." answers.
A comparison to any other specific system.
"Trac doesn't support Feature X" answers. I can read the feature list too, thank you very much.
I am looking for:
"Feature X does not behave as expected..."
"Trac behaves oddly when..."
"Trac doesn't fully support..."
"Trac itself has a known bug that will likely never be fixed..."
And especially "Trac can't handle..."
etc
So, what Trac-induced headaches do I have to look forward to?
For future reference, this question was asked while Trac v0.11 was the latest stable release.
There is still no common view on how to handle multi projects. If this is not your case - the rest should work for you.
One issue that I have run into with a long-term Trac instance is the 'version' field. There is no distinction between the list of versions that can be assigned to a ticket, and the list of versions that can be queried for in the custom query interface. So if the version list for that field starts getting cumbersomely long, you can't really trim it without limiting what you can search for.
One of these days I'll get around to fixing that...
Trac 0.11 is rather more of a resource hog than 0.10 was; in large part due to the switch to Genshi for the templating engine. You may want to keep an eye on resources on the server, memory in particular. I expect to see some increased attention paid to performance in 0.13 or so.
Oh, and if you run into problems, #trac on freenode can be a nice resource.
Disclosure: I'm one of the Trac developers
We've used Trac for several years with multiple projects. After thinking for a minute I still can't come up with any significant problem to list.
http://trac-hacks.org/ticket/131 - Persistent Logins (i.e. persistent login session cookies across browser restarts) is still not committed.
It means when you get your svn post-commit mail with the trac link then
if your browser isn't already loaded (remembering your login) you have to enter your credentials to see content (depending on how you have security set). This is only an issue if you only trust a certain class of users on your network. Browsers remembering credentials mitigate this, and for high-security situations you may not want the option at all, but for us it is slightly annoying.
0.12 is quite close to release, i would go straight for r9125 trunk or thereabouts:
multiple source repository support (branch landed in trunk with r9125)
live text editing previews
ticket comment editing with diffs are
those are three primaries why i went ahead and moved all my envs into 0.12dev. there are many more minor nice things that make a difference over 0.11, though.
i think running trac out of SVN working copy provides very nice upgrade and general manageability, so that is what i would recommend.
multiple project support is the biggest culprit so far and i'm looking to put in some work myself to improve that situation.
When someone else reassigns your ticket, you don't get notified.