[07:17] blr: Hm, you made h be next comment and l be previous comment? sort of feels backwards to me, perhaps because of Western left-to-right reading conventions [07:17] (yes, I should have looked at it during review ...) [08:13] cjwatson: if it feel weird, easy enough to change before people become too accustomed to it, although the 'forward' keys tend to be to the left of their backwards counterparts (realise there are vimisms there too) [08:18] cjwatson: wgrant: should `required=False` be sufficient to prevent clientside validation on a TextLine? It seems to be expecting a value, and I'm not certain why... would like the 'Optional' behaviour the copy_fields like branch_location have [08:23] blr: Our forms do no client validation by default. [08:23] Well, no client validation at all. [08:23] "Required input is missing."? [08:23] That's server-side. [08:24] required=False would normally fix that. [08:24] that's what I thought... hrm [08:24] Which field is it? [08:24] There's no vocab involved? [08:25] wgrant: just a barebones TextLine [08:25] with a title, required and description [08:26] might need to look at what the launchpad_form/widget_row is doing more closely [08:26] Huh, that's quite surprising. [08:27] blr: If you can't work it out this evening, throw a diff/branch at me or Colin and we can have a look. [08:27] wgrant: thanks [08:29] blr: Yeah, it may also be a vimism for me in that 'l' is very definitely a forward action in a file [08:32] cjwatson: hmm yes, perhaps it wouldn't hurt to swap them [08:33] h is certainly nicer to type, but there is precedent for the other way. [08:36] well given I like weird emacs chords, I'm probably the worst person to decide. [08:38] blr: Ah, so forward will be M-x Super-F12 Ctrl-Alt-f then? [08:38] StevenK: that sounds perfectly reasonable. [08:52] wgrant: cjwatson: did you see lifeless's new constraints feature for pip, pretty cool: https://github.com/pypa/pip/pull/2857/files [09:06] cute [15:57] hi all. any idea how to set up new git repository on launchpad? [15:58] redixin: https://help.launchpad.net/Code/Git [15:58] cjwatson: yes, but there is no info about setting up new repo. I can see only "import from git" option on launchpad project's page [15:59] but it does import from git to bzr [15:59] redixin: You just push to it [15:59] cjwatson: hm. I'll try. thanks [16:00] redixin: So for example if you want to push a default repository for an existing project named foo, "git remote add origin lp:foo && git push --all origin" or whatever [16:00] otherwise use one of the other URL forms [16:03] cjwatson: it works. thanks [16:04] Cool [21:52] Hey guys, I love to see how much effort are you pulling in lp development in last months - thank you :-) [21:52] you're welcome :) [21:53] rpadovani: lots more to come! [21:53] \o/ [21:59] cjwatson: still about? [21:59] blr: just [22:00] trying to understand the target argument for IGitRepositorySet.setDefaultRepository [22:00] presumably in the git context, not an IBranchTarget [22:01] blr: That's the target (IProduct or IDistributionSourcePackage; IPerson targets don't have defaults) that you're setting the default for [22:01] IBranchTarget is a confusing thing that I would like to refactor away soon [22:01] I didn't replicate it in the Git model [22:01] To the extent that it exists, it's mostly in GitNamespace [22:02] right okay [22:02] But anyway, here target means the actual target of the repository [22:03] For usage you could look at the GitRepositorySet tests or lp.code.xmlrpc.git [22:03] Or the interface docs :) [22:04] right, I think I was slightly thrown by IBranchTarget, I'll ignore it. [22:04] Yeah, I don't blame you [22:05] It took me quite a while to understand what it was doing [22:06] And you get awesome stuff like [22:06] lib/lp/code/stories/webservice/xx-branchmergeproposal.txt: >>> source = factory.makeBranchTargetBranch(target.target) [22:06] *crosses eyes* [22:10] cjwatson: wow, I'm strangely reminded of old java codebases there heh [22:10] Indeed! BranchTargetFactoryTargetBranchFactoryFactory [22:10] Bean [22:10] hah right, was going to say, forgot the Bean [22:39] wgrant: cjwatson: what's the best way to determine if product.development_focus is a git repo? [22:40] just check the type, or is there a helper somewhere? [22:40] blr: development_focus is a series. [22:40] It can't be a bzr branch or a git repo. [22:40] (a series can have a bzr branch, though) [22:41] err development_focus.branch [22:41] The project's main bzr branch is product.development_focus.branch, and the project's main git repo is getUtility(IGitRepositorySet).getDefaultRepository(product) [22:41] branch is always a branch. [22:41] (later on we'll probably allow a series to specify a branch name within the project's default git repo, but not at the moment) [22:42] okay, thanks [22:42] It's an unfortunate difference in the real-world model which complicates everything :) [23:05] wgrant: is there an equivalent of getUtility(IBranchLookup).getByUrl(branch_url) for a product? [23:05] where branch_url is in the lp:foo form? [23:05] blr: For a product? [23:06] You're in the context of a product. Why do you need to look one up? [23:07] wgrant: required to find the defaultrepository for 'another' product [23:07] blr: Oh, why are you doing that? [23:08] (you probably want getUtility(IProductSet).getByName('foo'), but I'm interested to know what you're doing.) [23:09] wgrant: hmm in the context of allowing a user to provide the url of another product to set their product's default git repository [23:09] perhaps my thinking around this is muddled. [23:09] blr: That's impossible. [23:09] It doesn't make sense, as is impossible in the model. [23:09] Do you have a use case for that? [23:10] in the mirror/fork case? [23:11] We don't support forking by creating another project. There are some situations where that is valid, but it requires an extensive rework of our project model to properly make sense. [23:12] ok, I suppose that clarifies that :) [23:12] We only support mirroring from external sites today, to discourage people from trying a GitHub-style model on the LP model where it doesn't fit. [23:12] (also to avoid security issues) [23:14] I wonder if that is a possible source of confusion for new users, given familiarity with github's model. [23:14] It is, but there are much worse ones. [23:15] We can mitigate it in a couple of obvious ways: [23:15] - Make it very clear how to push up your own branches to an existing project. [23:15] - Make the project creation form less insane, so people actually read the warnings on it. [23:15] right [23:15] Rather than "oh god there are 20 fields what am I doing let's just fill them in" [23:16] yep, there's far too much to think about up-front. [23:16] do you think we could safely set a default for licensing, but provide feedback to review it afterwards? [23:18] Yes, now that the commercial project model isn't nonsense, it's quite feasible. [23:20] We just ask private or public, and then bug them to select a license later. [23:20] (in fact, the "bug them to select a license later" workflow already exists, though it sucks, when you select "I don't know yet") [23:20] true [23:35] wgrant: I have a git 'foo', however getUtility(IGitRepositorySet).getByPath(self.user, '~kit/+git/foo') return None [23:36] git ^repo [23:38] blr: What's the git repo's target? That's a personal, not project, repo named 'foo'. [23:39] wgrant: a product [23:39] blr: getByPath('~kit/foo') is probably what you want. [23:39] Or just getByPath('foo') if it's the project's default. [23:40] oddly all None [23:40] ~kit/foo/+git/foo? [23:40] How did you create it? [23:41] the factory [23:41] ah, it'll have a weird name. [23:41] What was the exact command you used to create it? [23:42] It's probably ~kit/foo/+git/some-reasonably-random-string [23:42] just makeGitRepository() no args [23:42] Oh [23:42] Then it's not going to be foo, or owned by you, is it? [23:42] wgrant: it is, just using foo for illustrative purpose [23:42] ah ownership ugh [23:43] thanks, no doubt that's it :P [23:43] Heh [23:51] blr: Remember that repo.git_identity can get you the shortest path that will work for getByPath [23:53] oh that's handy [23:55] Not if you don't remember to store the repo in a local variable first, though :P