Fork me on GitHub
#tools-deps
<
2018-06-18
>
cfleming01:06:48

@hagmonk That looks lovely!

😄 4
cfleming01:06:31

Searching is by artifact/group name, right? AFAIK you can’t use the Maven APIs to search for namespace names?

hagmonk01:06:14

yes, just the group/artifact string

cfleming01:06:29

We really need something like Maven’s search by classname for namespaces and vars, but the indexing required for that is non-trivial.

hagmonk01:06:23

right, I did some poking around the crossclj sources, seems like the fellow maintaining that has taken a step back from it

cfleming01:06:34

Yes, he has

cfleming01:06:00

I’m not sure he maintained it much past the initial implementation, but I might be wrong there.

hagmonk01:06:21

It would be great to have a CLJ/CLJS source code index that also tracked the source repo and any built artifacts spun out of that

cfleming01:06:38

I have a question about deps support for Cursive. As I envision it, each deps project (i.e. a deps.edn, basically) would be a module in IntelliJ, so modules will be created for local deps etc, and libraries created for git deps.

cfleming01:06:15

My problem is that modules have to be given a name, and it has to be something that I can uniquely determine from the deps.edn file, which AFAIK doesn’t provide anything like that.

cfleming01:06:41

The only thing that I can think of is to use the name of the containing directory. Does that seem like a reasonable convention?

alexmiller03:06:52

We have talked about this a lot in the context of git deps. I don’t have time to write it all now will try to hit this tomorrow

cfleming01:06:32

I could also allow a name to be provided in a :cursive/name my-module entry in the deps map, assuming that sort of thing is allowed.

cfleming01:06:24

Oh, and one restriction is that modules have to have unique names.

hagmonk01:06:25

I think the general sentiment has been to keep deps.edn uncluttered with anything not related to building a classpath or running the program. Whether unrelated keys are preserved seems to be by chance rather than design

hagmonk01:06:03

but you just need a name for the module, it doesn't need to be the same as, say, the official maven artifact name

cfleming01:06:05

However, I doubt Cursive is the only system that would find it useful to assign a name to a project.

cfleming01:06:30

True, but there’s literally nothing there to base it off right now.

cfleming01:06:50

I mean, I could use the sha of the path to the project, but no-one is likely to be happy with that 🙂

hagmonk01:06:30

haha, what? who here doesn't love a full length SHA? :)

cfleming01:06:27

Hey, it’s (almost) guaranteed unique!

hagmonk01:06:00

I'm just looking through the tools on https://github.com/clojure/tools.deps.alpha/wiki/Tools (which I have to update with find-deps and mbuczko/revolt) to see what conventions exist for project name, in those cases where one is needed

cfleming01:06:09

As I understand it, if there are two projects which both refer to a common library using a local ref, there’s no requirement even for the name they assign to it to be unique.

cfleming01:06:54

i.e. project1: foo/bar {:local/root "../lib"} and project2: baz/bup {:local/root "../lib"}

cfleming01:06:50

In fact, I have no idea where those names are used, if anywhere

hagmonk01:06:14

I suppose the resolved path to the dep is what actually matters there, rather than the symbol. I'm not aware of any use for it either

hagmonk01:06:50

I guess one could also look at any git metadata in the project folder - perhaps prefer that, then fall back to directory name

cfleming01:06:17

I guess I could use the path from the main project root as the module name, but that will get weird if the local root is outside the main project.

cfleming01:06:40

I don’t know if IntelliJ has restrictions on what modules can be called, actually.

cfleming02:06:15

The problem with git metadata is that Cursive then needs git capabilities as well as maven capabilities

hagmonk02:06:37

plus it won't always exist

hagmonk02:06:26

perhaps the basename of the resolved path of the dep is good enough for most cases? If there is a name clash it might be worth foisting that on the user anyhow

cfleming02:06:55

That’s basically the name of the containing directory, right?

hagmonk02:06:12

Right - or even "basename-1/basename" ... most of my projects would be sensibly named with that convention

cfleming02:06:24

I guess I’m worried about cases like server/api/deps.edn and client/api/deps.edn

cfleming02:06:58

I’ll see if I can find out whether there are restrictions on module names.

cfleming02:06:20

I think I’ll just have to implement things until people stop complaining.

😂 4
hagmonk02:06:09

That is the zen of software development right there!

cfleming02:06:30

The problem with foisting it on the user is that there’s no way to store a customisation for the name within the IntelliJ project - I have to return a project structure based on a list of deps.edn files, no more.

cfleming02:06:52

Indeed - I think of it as a dynamic search algorithm.

cfleming02:06:45

@alexmiller I’m interested if there’s an official position on keys like :cursive/name my-module in deps files.

seancorfield03:06:03

@cfleming I don't know how "official" it is but whenever the subject has come up, Alex has always discouraged people adding "random" keys to the file...

hagmonk03:06:00

Also anecdotal, but listening to Rich on the cognitect podcast (when will they fix the audio?) I heard him say how nice it was to look at a deps.edn file and see “only deps” in there …

cfleming03:06:01

I guess I can always have a cursive.properties file alongside the deps.edn, but that seems way uglier to me.

cfleming03:06:26

Well, except it’s not only deps.

cfleming03:06:45

I mean, there are tasks with aliases etc etc as well.

cfleming03:06:55

Anyway, I’ll wait and see what Alex says.

hagmonk03:06:32

That was my thought too, I think it’s more accurate to say it contains “keys required to build a classpath and invoke the JVM with that classpath”

seancorfield03:06:38

There's an argument that Leiningen's project.clj sets a precedent for allowing additional tool-specific keys...

hagmonk03:06:36

I think tools.deps is a deliberate move away from that - where is the sweet spot though? Should the canonical name for the project be something in the deps file? It’s not really a tool-specific thing at all. Ironically, the deps file is a list of canonical names for other projects, or at least the names they go by in their repos

seancorfield03:06:03

I would say that deps.edn goes a long way toward removing the importance of names -- you can give arbitrary names to local and Git deps. The names of Maven deps really only exist to match up with group/artifact names that are published. When you depend on, say, a Gist, or some code in a random directory, the name is unimportant and synthetic for the most part...

cfleming03:06:58

Sadly, my users are not going to want shas as their module names.

cfleming03:06:58

They’re fine in a gist link, but not for a descriptive name for someone who wants to get an overview of their project.

hagmonk03:06:01

These are the kind of highfalutin customers @cfleming's software attracts :)

cfleming03:06:41

They’re so fussy.

hagmonk03:06:38

For some reason I'm reminded of Ghostbusters: "I've worked in the private sector … they expect results"

cfleming03:06:53

It does sometimes help to imagine myself as Bill Murray when I have to do this stuff.